oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zimdars, Paul A (3880-Affiliate)" <Paul.A.Zimd...@jpl.nasa.gov>
Subject Re: TestCatalog sql issues?
Date Wed, 23 Feb 2011 08:55:10 GMT
Brian,

Excellent. I will give it a try.

Thanks!
Paul
626-824-1393

On Feb 23, 2011, at 12:51 AM, "Brian Foster" <holenoter@mac.com> wrote:

> 
> NOTE: the patch was applied to the trunk, however if you want to use 0.2, i attached
the patch to OODT-115 if you want to apply it to your 0.2 unit-test.
> 
> -brian
> 
> On Feb 22, 2011, at 11:39 PM, Paul Zimdars wrote:
> 
>> Hi All,
>> 
>> I ran into some build issues with version 0.2 tonight and I thought I would share
my experiences. Here is my error output:
>> 
>> Test set: org.apache.oodt.cas.catalog.system.impl.TestCatalogServiceLocal
>> -------------------------------------------------------------------------------
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.379 sec <<<
FAILURE!
>> testDataSourceCatalogIngestQueryAndDelete(org.apache.oodt.cas.catalog.system.impl.TestCatalogServiceLocal)
 Time elapsed: 0.04 sec <<< ERROR!
>> org.apache.oodt.cas.catalog.exception.CatalogServiceException: Failed to get metadata
for transaction ids for catalog 'TestCatalog2' : Failed to get term buckets for transaction
id '2acba93b-878a-45c4-97cd-05496d5419c5' : Table not found in statement [SEL
>> CT bucket_name,term_name,term_value FROM transaction_terms]
>>   at org.apache.oodt.cas.catalog.system.impl.CatalogServiceLocal.getMetadata(CatalogServiceLocal.java:882)
>>   at org.apache.oodt.cas.catalog.system.impl.TestCatalogServiceLocal.testDataSourceCatalogIngestQueryAndDelete(TestCatalogServiceLocal.java:97)
>> Caused by: org.apache.oodt.cas.catalog.exception.CatalogException: Failed to get
term buckets for transaction id '2acba93b-878a-45c4-97cd-05496d5419c5' : Table not found in
statement [SELECT bucket_name,term_name,term_value FROM transaction_terms]
>>   at org.apache.oodt.cas.catalog.system.Catalog.getMetadata(Catalog.java:293)
>>   at org.apache.oodt.cas.catalog.system.impl.CatalogServiceLocal.getMetadata(CatalogServiceLocal.java:878)
>>   ... 27 more
>> Caused by: org.apache.oodt.cas.catalog.exception.QueryServiceException: Failed to
get term buckets for transaction id '2acba93b-878a-45c4-97cd-05496d5419c5' : Table not found
in statement [SELECT bucket_name,term_name,term_value FROM transaction_terms]
>>   at org.apache.oodt.cas.catalog.struct.impl.index.DataSourceIndex.getBuckets(DataSourceIndex.java:355)
>>   at org.apache.oodt.cas.catalog.system.Catalog.getMetadata(Catalog.java:287)
>>   ... 28 more
>> Caused by: java.sql.SQLException: Table not found in statement [SELECT bucket_name,term_name,term_value
FROM transaction_terms]
>>   at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
>>   at org.hsqldb.jdbc.jdbcStatement.fetchResult(Unknown Source)
>>   at org.hsqldb.jdbc.jdbcStatement.executeQuery(Unknown Source)
>>   at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:205)
>>   at org.apache.oodt.cas.catalog.struct.impl.index.DataSourceIndex.getBuckets(DataSourceIndex.java:341)
>>   ... 29 more
>> 
>> I found an old post that recommended setting -Djava.io.tmpdir and/or making /tmp
writeable by user but unfortunately that did not resolve the problem. It appears that even
though -Djava.io.tmpdir is set there are still parts of maven that use /tmp to store files
specifically during the TestCatalogService portion of the build process.  The following files/directories
are created in /tmp during the TestCatalog process:
>> 
>> /tmp/1
>> /tmp/2
>> /tmp/testMapperCat.log
>> /tmp/testMapperCat.properties
>> /tmp/testMapperCat.script
>> 
>> These files are not cleared out after the build process is complete. If by chance
another user on the system had recently built oodt on the same system (and tmpwatch didn't
clean out the stale /tmp files) then the next user who attempts to build will run into the
unit failures I mentioned above (with no clear idea that conflicting files in /tmp were causing
the problem). I also ran into the error above if I forget to clean out my own leftover /tmp
files (while doing a mvn clean install).
>> 
>> Paul
>> 
>> 
> 

Mime
View raw message