The unit test within activemq-core: org.apache.activemq.store.kahadb.KahaDBVersionTest, within the source distribution bundle for fuse 5.4.2-fuse-01-00 hangs.
With the source distribution of activemq from apache, this test takes around 10-15seconds to complete.
When the test hangs you will see the following in activemq-core/target/activemq-test.log:
Dominic-Tootells-MacBook-Pro-2:target dominict$ more activemq-test.log
2011-02-16 10:44:46,683 main INFO PListStore - PListStore:target/activemq-data/localhost/tmp_storage started
2011-02-16 10:44:46,690 main INFO BrokerService - Using Persistence Adapter: KahaDBPersistenceAdapter
2011-02-16 10:44:46,730 main INFO Journal - Corrupt journal records found in 'target/activemq-data/kahadb/versionDB/db-1.log' between offsets: 72
2011-02-16 10:44:47,181 main INFO MessageDatabase - KahaDB is version 872415232
2011-02-16 10:44:47,183 main ERROR BrokerService - Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException
2011-02-16 10:44:47,461 main INFO BrokerService - Using Persistence Adapter: KahaDBPersistenceAdapter
2011-02-16 10:44:47,461 main INFO MessageDatabase - Database target/activemq-data/kahadb/versionDB/lock is locked... waiting 10 seconds for the database to be unlocked. Reason: java.io.IOException: File 'target/activemq-data/kahadb/versionDB/lock' could not be locked as lock is already held for this jvm.
This issue seems to stem from two kahadb data directories that are part of the source distribution within the activemq-core module:
ls -l src/test/resources/org/apache/activemq/store/kahadb/
drwxr-xr-x@ 5 dominict staff 170 15 Feb 21:21 KahaDBVersion1
drwxr-xr-x@ 5 dominict staff 170 15 Feb 21:21 KahaDBVersion2
Replacing these directories with those, that come with apache 5.4.2 activemq distribution, makes the issue go away; and the unit test run in the normal 10-15seconds.
My question is:
A) Is this "failing" data a representation of a some state that the kahadb persistence store can get into, and an activemq instance could fail with this issue?
B) Is this data just some bad kahadb data that would never occur in a live broker scenario?
(Sorry I don't seem to be able to create a jira issue in the issue tracker for the above)
Thanks in advance