activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Strasheim (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1490) Deadlocks (with JUnit tests)
Date Wed, 14 Nov 2007 12:49:27 GMT

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

Albert Strasheim commented on AMQ-1490:
---------------------------------------

This is starting to sound like an issue I reported some time back, namely AMQ-1148, which
hasn't received much attention in recent months.

There is nothing in the JMS specification to indicate that one should use separate connections
for producers and consumers and doing so can have various implications for the design of an
application, so I would agree with Rainer Klute that this is something that should probably
be looked at carefully.

> 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
>             Fix For: 5.0.0
>
>         Attachments: ActiveMQ_Testcases.jar
>
>
> 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.


Mime
View raw message