activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer Klute (JIRA)" <>
Subject [jira] Commented: (AMQ-1490) Deadlocks (with JUnit tests)
Date Thu, 29 Nov 2007 11:15:27 GMT


Rainer Klute commented on AMQ-1490:

The good news is: Yes, it works! Great! Thanks, Rob!

The bad news is: Some test cases take a tremendous amount of heap space now. My former max
memory setting of -Xmx256K was insufficient; with -Xmx1024K the test application runs. This
gave me cause to investigate that behaviour more closely and I had jconsole watch the memory
usage. The result you'll find in attachment AMQ-1490_memory-001.png. I did some drawing on
that screenshot to demarcate the test cases. The wall clock times on the X axis you can correlate
to the detailed test case protocol in AMQ-1490_result-001.txt.

The scenario is that two producers send each 100,000 messages to a topic and one consumer
reads them all. The differences between them are whether producing and consuming sessions
are transactional or not.

Interesting results:
* The enormous memory consumption only occurs if the producers operate transactionally and
the consumer does not.
* Test case 0001 (transactional producers) starts to consume much memory. However, after a
mark-and-sweep garbage collection things stay moderate.
* The execution times vary very much: There's a factor of 7.7 between the fastest and the
slowest run.
* The fastests test cases are those without transactional producers.

> Deadlocks (with JUnit tests)
> ----------------------------
>                 Key: AMQ-1490
>                 URL:
>             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, ActiveMQ_Testcases.jar, ActiveMQ_Testcases.jar,
ActiveMQ_Testcases.jar, AMQ-1490_memory-001.png
> 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(
>   java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(
>  java.util.concurrent.ArrayBlockingQueue.take(
>  org.apache.activemq.transport.FutureResponse.getResult(
>  org.apache.activemq.transport.ResponseCorrelator.request(
>  org.apache.activemq.ActiveMQConnection.syncSendPacket(
>  org.apache.activemq.TransactionContext.commit(
>  org.apache.activemq.ActiveMQSession.commit(
>  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(
>  org.apache.activemq.MessageDispatchChannel.dequeue(
>  org.apache.activemq.ActiveMQMessageConsumer.dequeue(
>  org.apache.activemq.ActiveMQMessageConsumer.receive(
>  org.apache.activemq.ActiveMQMessageConsumer.receive(
> 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.

View raw message