ERROR XBM0J: Directory /tmp/paxexam_runner_hudson/TESTDB already exists.
------------------------------------------------------------------------
Key: ARIES-326
URL: https://issues.apache.org/jira/browse/ARIES-326
Project: Aries
Issue Type: Improvement
Components: Transaction
Affects Versions: 0.1
Reporter: Bartosz Kowalewski
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
org.apache.derby.impl.services.monitor.StorageFactoryService$9.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.derby.impl.services.monitor.StorageFactoryService.createServiceRoot(Unknown
Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(Unknown
Source)
at
org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Unknown
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.