Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-01-04T22:30:28ZEcoinformatics Redmine
Redmine Bug #4645 (Resolved): handleGetRevisionAndDocTypeAction should search both xml_documents and xml_...https://projects.ecoinformatics.org/ecoinfo/issues/46452010-01-04T22:30:28ZJing Taotao@nceas.ucsb.edu
<p>handleGetRevisionAndDocTypeAction API will return both revision and doctype for a given docid. Currently, it only searchs the xml_documents. It may gives clients a wrong message in this case:</p>
<p>There is no record in xml_documents, but it did have records in xml_revision table.</p>
<p>Here is the solution:</p>
<p>1. Search xml_documents table first. If metacat finds a result, returns it back to client.<br />2. If couldn't find result in xml_documents, then search xml_revisions table.</p> Bug #4644 (Resolved): Convert build to pull eml from svn instead of cvshttps://projects.ecoinformatics.org/ecoinfo/issues/46442010-01-04T18:11:06ZMichael Daigledaigle@nceas.ucsb.edu
<p>updated build.xml to get eml from svn</p> Bug #4637 (Resolved): Metacat Harvester fails to catch some insert and update failureshttps://projects.ecoinformatics.org/ecoinfo/issues/46372009-12-17T19:34:31ZDuane Costadcosta@lternet.edu
<p>Metacat Harvester is not catching all insert and update errors.</p>
<p>Recently at LTER, there have been a handful of documents that have been reported by Metacat Harvester as successful inserts or updates, but in fact the documents are not being successfully inserted or updated into Metacat. <br />The logical error is in method HarvesterDocument.putMetacatDocument(). The problem is that Harvester treats the absence of an exception as a success condition, when it should instead require hard confirmation of success from the Metacat client that the insert or update operation succeeded:</p>
<pre><code>if (harvester.connectToMetacat()) {<br /> try {<br /> if (insert) {<br /> metacatReturnString = metacat.insert(docidFull, stringReader, null);<br /> inserted = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.InsertDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> else if (update) {<br /> metacatReturnString = metacat.update(docidFull, stringReader, null);<br /> updated = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.UpdateDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> }<br /> catch (MetacatInaccessibleException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "MetacatInaccessibleException", e);<br /> }<br /> catch (InsufficientKarmaException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "InsufficientKarmaException", e);<br /> }<br /> catch (MetacatException e) {<br /> logMetacatError(insert, metacatReturnString, "MetacatException", e);<br /> }<br /> catch (IOException e) {<br /> logMetacatError(insert, metacatReturnString, "IOException", e);<br /> }</code></pre>
<p>Harvester does not check the value of the string returned by Metacat ('metacatReturnString' in the above code). In the cases where the insert/update operations have been failing, the return string is empty or null. Harvester should examine the return string to confirm that it contains the substring "<success>" or something similar.</p>
<p>The fact that no exception is thrown by Metacat could point to an additional problem in Metacat, since the insert/update operation completes without raising an exception even though the document is not inserted or updated. The documents that appear to trigger this condition are unusually large EML documents (currently there are three documents from CDR and one document from LUQ that trigger this bug).</p>
<p>After the Harvester bug is resolved, or as part of resolving it, further investigation should be done to determine whether there is also a Metacat bug involved here, and if there is, a separate bug entry should be entered for it.</p> Bug #4616 (Resolved): Timed Replication takes many hours and drives the load up on KNBhttps://projects.ecoinformatics.org/ecoinfo/issues/46162009-12-09T16:46:08ZMichael Daigledaigle@nceas.ucsb.edu
<p>Timed replication can more than 12 hours lter and almost that long for PISCO.</p>
<p>During that time, the load on the machine can surpass 10 and java can use over 200% cpu.</p>
<p>lter has over 80K records and pisco over 60K. Only a handful of those actually need to be replicated. We need to see why it's taking so long and using so many resources.</p> Bug #4594 (Resolved): Cannot insert replication server via guihttps://projects.ecoinformatics.org/ecoinfo/issues/45942009-12-02T22:27:45ZMichael Daigledaigle@nceas.ucsb.edu
<p>When attempting to add a replication record via the gui at</p>
<pre><code>&lt;metacat_context_url&gt;/style/skins/dev/replControl.html</code></pre>
<p>metacat throws an error:</p>
<pre><code>duplicate key value violates unique constraint "xml_replication_pk"</code></pre> Bug #4588 (Resolved): Install parc metacathttps://projects.ecoinformatics.org/ecoinfo/issues/45882009-12-01T00:23:08ZMichael Daigledaigle@nceas.ucsb.edu
<p>installed PARC metacat on data.palmyraresearch.org. Here are the steps I took:</p>
<p>mkdir /var/parc<br /> chown webuser:webuser /var/parc<br />sudo su - postgres<br />createdb parc<br />psql parc<br />CREATE USER parc WITH UNENCRYPTED PASSWORD '<password>';<br /> (note <password> is same as esa)</p>
<p>cp /etc/http/conf/http.conf to http.conf.20091130<br />vi /etc/http/conf/http.conf and added following section (note different IP than esa):<br /> <VirtualHost 128.111.242.17:80><br /> DocumentRoot /var/www/org.palmyraresearch.data/catalog/style/skins/parc<br /> ServerName data.palmyraresearch.org<br /> ErrorLog /var/log/httpd/error_log<br /> CustomLog /var/log/httpd/access_log common</p>
<pre><code>ScriptAlias /catalog<br />/cgi-bin/ "/var/www/org.palmyraresearch.data/catalog/cgi-bin/" <br /> &lt;Directory "/var/www/org.palmyraresearch.data/catalog/cgi-bin/"&gt;<br /> AllowOverride None<br /> Options ExecCGI<br /> Order allow,deny<br /> Allow from all<br /> &lt;/Directory&gt;</code></pre>
<pre><code>&lt;Directory "/var/www/org.palmyraresearch.data/catalog/style/skins/parc"&gt;<br /> AllowOverride none<br /> Options Indexes FollowSymLinks<br /> IndexOptions FancyIndexing<br /> &lt;/Directory&gt;</code></pre>
<pre><code>&lt;Location "/var/www/org.palmyraresearch.data/catalog/style/skins/parc/parc.cfg"&gt;<br /> AllowOverride None<br /> Order allow,deny<br /> Deny from all<br /> &lt;/Location&gt;</code></pre>
<pre><code>JkMount /catalog ajp13<br /> JkMount /catalog/* ajp13<br /> JkMount /catalog/metacat ajp13<br /> JkUnMount /catalog/cgi-bin/* ajp13<br /> JkMount /*.jsp ajp13<br /> JkMount /authority ajp13<br /> JkMount /authority/* ajp13<br /> &lt;/VirtualHost&gt;</code></pre>
<p>mkdir /var/www/org.palmyraresearch.data<br /> chown webuser:webuser /var/www/org.palmyraresearch.data</p>
<p>scp knb.war from build machine to data.palmyraresearch.org:/tmp<br /> mv /tmp/knb.war /var/www/org.palmyraresearch.org/catalog.war<br /> chown webuser:webuser /var/www/org.palmyraresearch.data/catalog.war</p>
<p>Edit /usr/local/devtools/jakarta-tomcat/conf/server.conf and added following lines:<br /> <Host name="data.palmyraresearch.org" debug="0" appBase="/var/www/org.palmyraresearch.data" <br /> unpackWARs="true" autoDeploy="true" <br /> xmlValidation="false" xmlNamespaceAware="false"><br /> <Logger className="org.apache.catalina.logger.FileLogger" <br /> directory="/var/log/tomcat" prefix="data_parc_log." suffix=".log" <br /> timestamp="true"/><br /> </Host></p>
<p>/etc/init.d/http stop<br />/etc/init.d/tomcat stop<br />/etc/init.d/tomcat start<br />/etc/init.d/http start</p>
<p>chmod +x /var/www/org.palmyraresearch.data/catalog/cgi-bin/*</p>
<p>go to data.palmayraresearch.org/catalog and step through config utility<br /> -- added appropriate administrators<br /> -- set /var/parc as the root dir for all data, temp etc directories<br /> -- configured db credentials<br /> -- made parc skin default.</p> Bug #4557 (Resolved): TPC Sanparks page content lenth issuehttps://projects.ecoinformatics.org/ecoinfo/issues/45572009-11-18T20:38:19ZMichael Daigledaigle@nceas.ucsb.edu
<p>If the content of a tpc list page gets to long, it breaks the page. Need to adjust the page length based on the list length.</p> Bug #4556 (Resolved): Fix cross platform TPC GUI issueshttps://projects.ecoinformatics.org/ecoinfo/issues/45562009-11-18T20:25:07ZMichael Daigledaigle@nceas.ucsb.edu
<p>The new TPC Sanparks skins break on different OSs. Specifically, they don't work well on Windows in IE.</p> Bug #4420 (Resolved): Enforce permissions for tpc workflow viewing and schedulinghttps://projects.ecoinformatics.org/ecoinfo/issues/44202009-09-28T16:20:38ZMichael Daigledaigle@nceas.ucsb.edu
<p>The existing squery functionality handles the visibility of workflows for the appropriate users.</p>
<p>The schedule link for each workflow should be active only for users that have read permissions on the associated kar file.</p> Bug #4167 (Resolved): Create Workflow Schedulerhttps://projects.ecoinformatics.org/ecoinfo/issues/41672009-06-16T15:01:41ZMichael Daigledaigle@nceas.ucsb.edu
<p>Create a scheduling web service that can schedule jobs for the kepler workflow engine.</p> Bug #4166 (Resolved): Create archive extraction functionalityhttps://projects.ecoinformatics.org/ecoinfo/issues/41662009-06-16T14:54:21ZMichael Daigledaigle@nceas.ucsb.edu
<p>Create the ability for metacat to read data from an archive. This will extract the archive an get the desired file.</p> Bug #4165 (Resolved): Create TPC Report web browse/search pageshttps://projects.ecoinformatics.org/ecoinfo/issues/41652009-06-16T14:48:57ZMichael Daigledaigle@nceas.ucsb.edu
<p>Create TPC search and browse skins in the sanparks skin.</p> Bug #3885 (Resolved): KNB metacat replication error log file is emptyhttps://projects.ecoinformatics.org/ecoinfo/issues/38852009-03-12T17:46:59ZJing Taotao@nceas.ucsb.edu
<p>In the new 1.9.0 knb metacat, it seems the replication log files' name are changed. Somehow the error log file is empty - but it shouldn't since we know some eml documents were not replicated successfully.</p>
<p>Duane sent us an email with a replication error log file. That file is not empty and this means that the replication error log works on lter metacat.</p> Bug #3729 (Resolved): Add admin names as dropdown in configuration loginhttps://projects.ecoinformatics.org/ecoinfo/issues/37292009-01-07T16:32:33ZMichael Daigledaigle@nceas.ucsb.edu
<p>Currently the user has to type in the full distinguished admin name to log in using ldap.</p>
<p>Instead, it would be nice if a dropdown of existing configured admins was available.</p> Bug #3510 (Resolved): reorganize classes into a more functional specific structurehttps://projects.ecoinformatics.org/ecoinfo/issues/35102008-10-08T22:44:59ZMichael Daigledaigle@nceas.ucsb.edu
<p>Currently the classes are organized by the type of class, (service, utility, etc). They should be reorganized into a functional structure.</p>