[ https://issues.apache.org/activemq/browse/AMQ-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40869 ] Rainer Klute commented on AMQ-1490: ----------------------------------- Rob, I am presently running my test cases * without the one with the large transaction size but * with more messages than before (500,000 per producer, with 2 producers and 1 consumer). The flow control issues seems indeed to be solved, so yes, we can close this issue. However, with the increase of the number of messages, I get all sorts of errors from the AMQ store, i.e. * notes about messages that could not have been entered into the store because of an IndexOutOfBoundException, and * notes about messages that could not have been recoved from the store. Before creating another issue, I'll update to the very latest ActiveMQ snapshot and retry. > Deadlocks (with JUnit tests) > ---------------------------- > > Key: AMQ-1490 > URL: https://issues.apache.org/activemq/browse/AMQ-1490 > Project: ActiveMQ > Issue Type: Bug > Components: Broker > Affects Versions: 5.0.0 > Environment: Linux > Reporter: Rainer Klute > Assignee: Rob Davies > Fix For: 5.0.0 > > Attachments: ActiveMQ_Testcases.jar, AMQ-1490_memory-001.png, AMQ-1490_result-001.txt > > > For some time now there have been various bug reports about ActiveMQ "blocking", "not receiving messages", "running into a deadlock" etc. Since I encoutered such deadlocks now and then, too, I eventually wrote up a JUnit testing scenario for this stuff. I found out that deadlocks can be quite easily reproduced. The symptoms are that the producer thread is sending or committing while the consumer thread is receiving or committing - and none of them can advance. One of the threads is always stuck in a blocking queue. > Here's a sample output of my testing class: > An ActiveMQ deadlock has been discovered. The following threads seem to be involved: > Thread "producer" is inactive since 16 seconds after 358719 status changes. The current status is COMMITTING > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1889) > java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:317) > org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40) > org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:76) > org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1172) > org.apache.activemq.TransactionContext.commit(TransactionContext.java:259) > org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:494) > de.rainer_klute.activemq.ProducerThread.run(ProducerThread.java:162) > Thread "consumer" is inactive since 16 seconds after 1807 status changes. The current status is RECEIVING > java.lang.Object.wait(Native Method) > java.lang.Object.wait(Object.java:485) > org.apache.activemq.MessageDispatchChannel.dequeue(MessageDispatchChannel.java:75) > org.apache.activemq.ActiveMQMessageConsumer.dequeue(ActiveMQMessageConsumer.java:404) > org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:452) > org.apache.activemq.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:504) > de.rainer_klute.activemq.ConsumerThread.run(ConsumerThread.java:183) > The following factors seem to increase the probability of a deadlock: > * small values for memoryUsage > * working transacted in the consumer (not always necessary but "helps") > * many messages in the persistence store (to be achieved via a long delay before the consumer starts to read messages) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.