Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362017-05-11T14:19:25ZEcoinformatics Redmine
Redmine Bug #7188 (Resolved): MNodeService.replicate() is failinghttps://projects.ecoinformatics.org/ecoinfo/issues/71882017-05-11T14:19:25ZChris Jonescjones@nceas.ucsb.edu
<p>Laura Moyers reported that she is seeing many failed replication attempts in the Coordinating Node index. In particular, KNB, GOA, UIC, ARCTIC, mnUCSB1, and mnORC1 are all affected, and are all running Metacat.</p>
<p>After looking at catalina.out on the MNs, we're seeing errors in <code>MNodeService.replicate()</code>:<br /><pre>
20170508-06:59:14: [ERROR]: Error computing checksum on replica: mark/reset not supported [edu.ucsb.nceas.metacat.dataone.MNodeService]
</pre></p>
<p>Here's the number of requests and failures<br /><pre>
host requests failures failures_since
-----------------------------------------------------------
mn-orc-1 145 25 20170511-01:23:48
mn-ucsb-1 105 56 20170508-06:59:14
mn-unm-1 0 0 -
knb 71 28 20170509-16:57:53
uic no log access
</pre></p>
<p>I'm pretty sure the failures represent 100% of the requests since the failures began, but we'd need to confirm this. Basically, MN replication looks to be entirely broken in Metacat.</p>
<p>The error reported above comes from line 866 of <code>MNodeService.java</code>, where the checksum of the bytes of the object from the source MN (to be replicated) is calculated. Once the checksum is calculated, we call <code>object.reset()</code> on the input stream so it can be read again when writing to disk. This is throwing the exception above.</p>
<p>So what's changed? The last changes regarding the <code>InputStream</code> was that Jing wrapped the calls in a <code>try{ } finally { }</code> block in order to ensure the input stream gets closed after use to prevent memory leaks. This doesn't seem like an issue at all, although the <code>finally{ }</code> block could have been used in the existing <code>try { }</code> block instead of having three levels of <code>try</code> nesting. This seems inconsequential though.</p>
<p>The other change is that <code>d1_libclient_java</code> is now using the Apache Commons IO <code>AutoCloseInputStream</code>. Looking at the documentation there, it seems to delegate to the underlying input stream implementation. We know that not all input streams support the <code>mark()</code> method and therefore can't be <code>reset()</code>, which is why we call <code>markSupported()</code> before attempting to calculate the checksum. So why is <code>markSupported()</code> succeeding, but then <code>reset()</code> is failing after reading the input stream? It seems like we need to track this down between the interaction of <code>MNodeService</code> and <code>MultipartMNode.getReplica()</code>.</p> Bug #6136 (Closed): files left open causes too many file descriptors on OShttps://projects.ecoinformatics.org/ecoinfo/issues/61362013-10-09T20:03:37ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat writes temp files to disk, and in the process has been failing to close file handles. Over time, especially with operations that touch many files, the number of file handles in use by Metacat increases and eventually exceeds the operating systems hard limit, causing exceptions when Metacat tries to open any additional files. Need to be sure to close all file handles properly after usage.</p> Bug #5523 (Resolved): setting authoritative MN and rightsHolder for KNB data on conversionhttps://projects.ecoinformatics.org/ecoinfo/issues/55232011-10-28T21:16:08ZMatt Jonesjones@nceas.ucsb.edu
<p>When EML and data in the NCEAS and LTER metacat is converted to use in the new KNB MN, we need to generate system metadata for each object.</p>
<p>For rightsHolder, I propose we use the current xml_documents.user_owner field.</p>
<p>For authoritativeNode, we should set that to the ID of either the KNB MN or the LTER Member Node (of course, we'll have to know what these node IDs are) as appropriate. This can probably be determine from the home server entry in our replication tables.</p> Bug #5514 (Resolved): implement DataONE service APIhttps://projects.ecoinformatics.org/ecoinfo/issues/55142011-10-26T19:15:48ZMatt Jonesjones@nceas.ucsb.edu
<p>Support the new DataONE service API for interoperable data repositories:</p>
<p><a class="external" href="http://mule1.dataone.org/ArchitectureDocs-current/">http://mule1.dataone.org/ArchitectureDocs-current/</a></p>
<p>Support all 4 teirs of operation.</p> Bug #5513 (Resolved): add support for DOI identifiers from EZIDhttps://projects.ecoinformatics.org/ecoinfo/issues/55132011-10-26T19:10:36ZMatt Jonesjones@nceas.ucsb.edu
<p>DOI identifiers can be created through the EZID service run by the California Digital Library. See:</p>
<p><a class="external" href="http://n2t.net/ezid/doc/apidoc.html">http://n2t.net/ezid/doc/apidoc.html</a><br /><a class="external" href="https://confluence.ucop.edu/display/Curation/Identifier+Conventions">https://confluence.ucop.edu/display/Curation/Identifier+Conventions</a></p>
<p>We should support the assignment of DOI identifiers for objects stored in Metacat. The current changes supporting arbitrary identifier formats in Metacat for the DataONE release should be sufficient for actually tracking the identifiers. But we also need to be able to register the identifiers with a DOI service when they are created locally. To do this, we need to decide on the appropriate model for how Metacat interacts with this service -- e.g., should we support automatic creation of DOIs for all objects as they are created? Or should we force people to use 'reserveIdentifier() with a DOI to create a DOI that they can then use to create their object. Another issue is whether we should create DOIs for all existing objects in the KNB or not.</p> Bug #5273 (Resolved): docs with inline-data allow invalid xml into metacathttps://projects.ecoinformatics.org/ecoinfo/issues/52732011-01-13T17:37:32ZChad Berkleyberkley@nceas.ucsb.edu
<p>If you insert a document with inline-data, the data is stripped out of the document before it is validated. However, when you do a GET on the document, it is read off of the disk. So if you insert a doc with inline-data that has invalid characters in it (like unescaped ampersands), metacat will not recognize that it is invalid, but when you try to get the document, you will get a parser error if you try to parse it.</p>
<p>We should be validating the document first before stripping inline-data out of it.</p> Bug #5234 (Resolved): Replication -- user does not have permission to update access rule for data...https://projects.ecoinformatics.org/ecoinfo/issues/52342010-10-29T20:26:24Zmike frenockmikef5094@gmail.com
<p>I have a group of files that aren't replicating with the error message that I don't have permission to update access rules for one of the data files. I'm the administrator and both databases (xml_access) show I have all(7) allow permissions on the file via the data-managers group.</p>
<p><frenockm_> knb 20101029-10:24:30: [ERROR]: ReplicationHandler.handleSingleXMLDocument - Failed to write doc pisco_recruitment.1374.1 into db because User: uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org does not have permission to update access rules for data file pisco_recruitment_UCSC.1 [ReplicationLogging]<br /><jing> then this is a bug. somebody change the code and the replication rules is broken.<br /><jing> you may file a bug about this.</p> Bug #5054 (Resolved): Unable to insert large EML documents and no error status returnedhttps://projects.ecoinformatics.org/ecoinfo/issues/50542010-06-18T21:24:22ZDuane Costadcosta@lternet.edu
<p>Two LTER sites (CDR and LUQ) have been unable to insert large EML documents into the LTER Metacat. The failure occurs both in batch mode (i.e. Metacat Harvester) and manually from a web form. There are really two problems:</p>
<p>1. The insert operation fails.</p>
<p>2. Metacat gives no indication that it fails. There is no apparent response of any kind other than that the insert operation terminates.</p>
<p>The following URL points to a very large (2+ MB) EML document with in-line data. Dan Bahauddin, Information Manager at Cedar Creek Ecosystem Science Reserve has granted permission to Metacat developers to access this document for the purpose of testing this bug (thanks, Dan!):</p>
<pre><code><a class="external" href="http://www.cedarcreek.umn.edu/data/emlFiles/knb-lter-cdr.70120.101.xml">http://www.cedarcreek.umn.edu/data/emlFiles/knb-lter-cdr.70120.101.xml</a></code></pre> Bug #5011 (Resolved): Add support for DataONE service APIhttps://projects.ecoinformatics.org/ecoinfo/issues/50112010-05-14T17:25:51ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat will be used within DataONE as both a Member Node and as a component of the Coordinating Node infrastructure. We need to add support for the proper REST APIs for DataONE, which are described here:</p>
<p><a class="external" href="http://mule1.dataone.org/ArchitectureDocs/index.html">http://mule1.dataone.org/ArchitectureDocs/index.html</a></p>
<p>Initial support should include the following methods:<br />MN.get()<br />MN.getSystemMetadata()<br />MN.listObjects()</p>
<p>CN.create()<br />CN.update()<br />CN.get()<br />CN.getSystemMetadata()<br />CN.resolve()</p>
<p>These tasks are a DataONE project, and so details are being tracked in the DataONE ticket system (<a class="external" href="http://trac.dataone.org">http://trac.dataone.org</a>). This is a tracking bug for the feature overall.</p> Bug #4641 (Resolved): must support java 1.6https://projects.ecoinformatics.org/ecoinfo/issues/46412009-12-19T01:57:22ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat currently runds under java 1.5.x, which is now at end-of-life for support. We must support JDK 1.6.x in the next release, and deprecate 1.5.x. This most likely involves changes to how we handle JDBC connections, and maybe a few other issues. If you know of additional compatibility issues, please list them here.</p> Bug #4367 (Resolved): metacat didn't update xml_path_index table while a document was updatedhttps://projects.ecoinformatics.org/ecoinfo/issues/43672009-09-04T17:09:51ZJing Taotao@nceas.ucsb.edu
<p>Hi Jing:</p>
<pre><code>Marissa Bauer, working on the POD project, created a new data package<br /> using Morpho - she has created about 25 of them so far. The latest<br /> accession # is mbauer.42.9.</code></pre>
<pre><code>Unlike the rest of the packages, this one is not included in the results of<br /> an NCEAS Data Repository search on the string 'POD!'. KNB portal<br /> and Morpho searches both to find the package.</code></pre>
<pre><code>Initially, Marissa did not include an organizationName field with NCEAS: 12192<br /> string in it,so I added that with the Morpho editor.</code></pre>
<pre><code>In any case, can you take a look at the DP (mbauer.42.9) and let me know what might be missing?</code></pre>
<pre><code>Thanks,<br /> Rick R</code></pre>
<pre><code>Hi, Rick:</code></pre>
<pre><code>Since you can find the mbauer.42.9 by searching in knb page and morpho, I thought this is a nceas skin filter issue. I looked the<br /> mbauser.42.9 and found it has the filter - organizationName="National Center for Ecological Analysis and Synthesis". I am confused<br /> - NCEAS skin should find it.</code></pre>
<pre><code>I carefully checked the nceas skin sql query and the metacat database, it turned out that xml_path_index table hasn't been updated<br /> since mbauer.42.5. When I run "select * from xml_path_index where docid like 'mbauer.42';", I got:</code></pre>
<pre><code>4196745 | mbauer.42 | @packageId | � � � � � � � � 0 | � �304886418 | mbauer.42.5<br /> .......<br /> 4196773 | mbauer.42 | organizationName | � � � � � � � � 0 | � �304886527 | NCEAS<br /> .......</code></pre>
<pre><code>You see, in xml_path_index table, the organizationName is "NCEAS", rather than "National Center for Ecological Analysis and<br /> Synthesis", so the nceas skin query couldn't catch the docid. Also we can see the package id is still mbauer.42.5. But the package<br /> id is mbauer.42.9 in document mbauer.42.9.</code></pre>
<pre><code>So I think it is a metacat bug - the xml_path_index table wasn't updated while the document was updated. In your case, the current<br /> document is mbauser.42.9, but the in xml_path_index is still mbuaser.42.5.</code></pre> Bug #4356 (Resolved): knb website query result shows old version of a documenthttps://projects.ecoinformatics.org/ecoinfo/issues/43562009-08-31T21:26:51ZJing Taotao@nceas.ucsb.edu
<blockquote><blockquote><blockquote><blockquote>
<p>Oliver Soong wrote:</p>
<blockquote>
<p>I dropped a note about this on IRC, and Matt suggested you two might<br />be the ones to hear about it. �If I search on KNB for Kruger, I can<br />turn up judithk.40.35, but if I adjust the URL to ask for<br />docid=judithk.40, I get judithk.40.40. �The package was just recently<br />replicated, so that may be part of the issue, but at the moment,<br />things seem to be out of sync. �I don't know if this is expected<br />(search index is slightly out of date?) or whether this represents a<br />more serious issue.</p>
<p>Oliver</p>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<p>Hi, Mike:</p>
<p>I think i found the problem. I queried the xml_queryresult table by "select * from xml_queryresult where docid like 'judithk.40';" and get something<br />like:</p>
<p>judithk.40 |<br /><docid>judithk.40.35</docid><docname>eml</docname><doctype>eml://ecoinformatics.org/eml-2.1.0</doctype><createdate>2004-07-20</createdate><updatedate>200<br />9-05-29</updatedate><param name="dataset/title">Kruger National Park ecological aerial survey data (1998-2007)</param><param<br />name="creator/individualName/surName">Kruger</param><param name="creator/organizationName">SANParks</param><param name="keyword">Ungulate<br />population</param><param name="keyword">Aerial survey</param><param name="keyword">Distance methodology</param><param name="keyword">SANParks, South<br />Africa</param><param name="keyword">Kruger National Park, South Africa</param><param name="keyword">Kruger National Park</param></p>
<p>You see, the judithk.40.35 is stored in the xml_queryresult table. I think there was a mechanism to delete the cached item when a document was updated.<br />It seems this mechanism was broken.</p>
<p>It was possible to delete some records in xml_queryresult table. But I am not sure if metacat still works this way. If this is the case, we can delete<br />the records for judithk.40 then i think the search will work.</p>
<p>I will file a bug report for this issue.</p>
<p>Thanks,</p>
<p>Jing</p> Bug #3908 (Resolved): replication data user permission errorhttps://projects.ecoinformatics.org/ecoinfo/issues/39082009-03-19T16:57:38ZMichael Daigledaigle@nceas.ucsb.edu
<p>From Jing</p>
<p>I observed some error message during the replication from LTER to KNB:<br /> Failed to write doc pisco_recruitment.314.1 into db because User does not have<br />permission to update of access rules for data file pisco_recruitment.120<br />[edu.ucsb.nceas.metacat.ReplicationHandler]<br />Metacat: [ERROR]: error to handle update doc in xml_documents in time<br />replicationUser does not have permission to update of access rules for data<br />file pisco_recruitment.120 [edu.ucsb.nceas.metacat.ReplicationHandler]<br />Metacat: [ERROR]: Error in Eml200SAXHanlder.handleOnlineUrlDataFile is User<br />does not have permission to update of access rules for data file<br />pisco_recruitment.120 [edu.ucsb.nceas.metacat.Eml200SAXHandler]</p>
<p>I think this is an issue ( which may NOT relative to Margaret's one). During<br />the replication, there no user login, so the user is null and it should have<br />all permission to write documents into the db. Obviously, this access control<br />rule was modified.</p> Bug #3906 (Resolved): Can't read files whose names are a pathhttps://projects.ecoinformatics.org/ecoinfo/issues/39062009-03-19T15:41:57ZMichael Daigledaigle@nceas.ucsb.edu
<p>During replication, Metacat is getting a lot of errors that look like:</p>
<p>knb 06:35:44,975: [ERROR]: error to handle update doc in xml_revisions in time replication<error>Error reading document /export/home/tcat/prd/metacat_data/metacat/documents/knb-lter-hfr.120.3 from disk: null</error></p> Bug #3881 (Resolved): Replication not working between KNB and LTER metacatshttps://projects.ecoinformatics.org/ecoinfo/issues/38812009-03-11T20:13:43ZMichael Daigledaigle@nceas.ucsb.edu
<p>After the 1.9.0 upgrade on knb and lter, docs are not replicating from knb to lter. Jing is working with Duane C to resolve this issue.</p>