You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Rainer Klute (JIRA)" <ji...@apache.org> on 2008/01/25 15:49:26 UTC

[jira] Reopened: (AMQ-1490) Deadlocks (with JUnit tests)

     [ https://issues.apache.org/activemq/browse/AMQ-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rainer Klute reopened AMQ-1490:
-------------------------------


Sorry, but I have to reopen this issue again!

While the test scenario "multiple producers, single consumer" seems to work fine in most cases, the scenario "one producer, multiple consumers" fails soon and reproducibly with just 2 consumers and as few as 6,000 messages. (In my production environment I'll have about 600 consumers and about 250 messages per second.)

I shall re-submit a further development of my JUnit test case shortly.

> 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.