aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hughes (JIRA)" <>
Subject [jira] Resolved: (ARIES-326) ERROR XBM0J: Directory /tmp/paxexam_runner_hudson/TESTDB already exists.
Date Fri, 28 May 2010 15:49:35 GMT


Jeremy Hughes resolved ARIES-326.

    Resolution: Fixed

The fix is in. We'll have to see whether Hudson is happy ...

> ERROR XBM0J: Directory /tmp/paxexam_runner_hudson/TESTDB already exists.
> ------------------------------------------------------------------------
>                 Key: ARIES-326
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Transaction
>    Affects Versions: 0.1
>            Reporter: Bartosz Kowalewski
>            Assignee: Jeremy Hughes
> Last 5 Aries builds were unstable. It seems to be really hard to reproduce the issue
with Derby DB that is observable on the build machine:
> Caused by: ERROR XBM0J: Directory /tmp/paxexam_runner_hudson/TESTDB already exists.
> 	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> 	at$ Source)
> 	at Method)
> 	at
> 	at Source)
> 	at
> 	at Source)
> 	... 48 more
> While I don't know what's the real source of this issue (as I cannot reproduce it on
my machine) and the SVN log does help a lot in investigating this problem, I have a proposal
for a change in the way Derby DB is used in Aries. This change might potentially also get
rid of the error that we are now observing on the build machine. 
> The embedded Derby data source that is used in transaction itests uses disk storage and
creates a TESTDB directory in the Pax Exam/Runner working dir. In case of the build machine
it is /tmp/paxexam_runner_hudson/TESTDB. Fortunately, the derby DB version that is used in
Apache Aries already supports an in-memory storage backend. It is suitable for tests - persistent
storage is not really required for the tests that are run in Aries. What is more, with this
backend there's no longer a need to care about files that must be deleted after test is finished.
> What would need to be changed?
> transaction\transaction-testds\src\main\resources\OSGI-INF\blueprint\dataSource.xml
> <property name="databaseName" value="memory:TESTDB"/>
> instead of
> <property name="databaseName" value="TESTDB"/>
> for both data sources defined in this file.
> I've just given it a try and it works on my machine. Derby DB does not leave any resources
after each of the tests (not really - it leaves a log file :) ). 
> Of course the fact that it works on my machine does not imply that it will fix the issue
that we're now observing on Hudson :). Nevertheless, I'd give it a try.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message