ActiveMq - Kaha - Store is locked ... wait 10 seconds to unlock Store

Question

I have two queues in my application (Spring3-Hibernate-ActiveMq). Thanks for your comments in advance. I would be glad if you help me avoid the following error:

10: 02: 41,541 INFO KahaStore: 463 - Kaha Store using the \ tmp \ kahadb data directory 10: 02: 41,542 INFO KahaPersistenceAdapter: 185 - The store is locked ... waiting 10 seconds to unlock the Store. 10: 02: 51,542 INFO KahaStore: 463 - Kaha Store using the \ tmp \ kahadb data directory 10: 02: 51,543 INFO KahaPersistenceAdapter: 185 - The store is locked ... waiting 10 seconds to unlock the Store. 10: 03: 01,543 INFO KahaStore: 463 - Kaha Store using the data directory \ tmp \ kahadb ...

And here is my applicationContext.xml

<amq:connectionFactory id="amqConnectionFactory" brokerURL="vm://localhost" /> <bean id="connectionFactory" class="org.springframework.jms.connection.CachingConnectionFactory"> <constructor-arg ref="amqConnectionFactory" /> <property name="sessionCacheSize" value="100" /> </bean> <bean id="jmsTemplateForProduct" class="org.springframework.jms.core.JmsTemplate" p:defaultDestinationName="Click.Queue.Product"> <constructor-arg ref="connectionFactory" /> </bean> <bean id="jmsTemplateForPayment" class="org.springframework.jms.core.JmsTemplate" p:defaultDestinationName="Click.Queue.Payment"> <constructor-arg ref="connectionFactory" /> </bean> <jms:listener-container concurrency="10"> <jms:listener id="ProductListener" destination="Click.Queue.Product" ref="productListener" /> </jms:listener-container> <jms:listener-container concurrency="10"> <jms:listener id="PaymentListener" destination="Click.Queue.Payment" ref="paymentListener" /> </jms:listener-container> <!-- ActiveMQ ends --> 

Answer 1

Ok, I solved the problem myself. BTW thanks jkysam for your comments.

The problem arose because loading the Context application more than once. Thus, when the applicationContext application loads, a new instance of kaha db is created, and this leads to blocking.

What I did was that I shared the jms configuration related to applicationContext. So, I created a new XML context file jmsContext.xml and moved the associated jms (and activemq) related configuration lines to this file. Then in my test classes I loaded different xml objects depending on whether it is jmsTest or not.

For instance; I have two GenericUnitTest classes to share context configuration. First:

 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"/jmsContext.xml"}) public abstract class GenericJmsUnitTest { } 

Second:

 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"/applicationContext.xml"}) public abstract class GenericUnitTest { } 

And then I extend these classes depending on the test case. Here is an example:

 public class ProductQueueTest extends GenericJmsUnitTest{ @Autowired private ProductQueueService productQueueService; @Test public void productTest() { productQueueService.sendProduct(); } } 

Sample non-jms test class:

 public class SchedularTest extends GenericUnitTest { @Autowired private Processor schedulerProcessor; @Test public void scheduleForProduct() { schedulerProcessor.processForProducts(); } } 

BTW, I exclude scanning filters for components that are queued in applicationContext.xml and include them in jmsContext.xml. Here is an example:

applicationContext xml below

 <context:component-scan base-package="com.project"> <context:exclude-filter type="regex" expression="com.project.queue.*"/> <context:exclude-filter type="regex" expression="com.project.test.queue.*"/> </context:component-scan> 

jmsContext xml is below

  <context:component-scan base-package="com.project.queue"/> <context:component-scan base-package="com.project.test.queue"/> 

Answer 2

Kaha is an ActiveMQ repository of continuous activity, and it has a lock file that prevents multiple AMQ processes from accessing simultaneously. On a clean exit, this lock will always be deleted, but if for some reason the process did not complete correctly, the lock cannot be removed. In addition, if you work with several brokers, they can by default use the same Kaha location, in your case \ tmp \ kahadb, and one of them will not go to the store. See Kaha Link for setting location reconfiguration.

If none of these scenarios is applicable to your situation, you may have a legitimate problem with the broker, but you need to provide more detailed information on how you will receive the lock verification code.