activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergiy Barlabanov (JIRA)" <>
Subject [jira] [Created] (AMQ-4166) RedeliveryPlugin causes a deadlock with JobSchedulerImpl
Date Fri, 09 Nov 2012 10:58:12 GMT
Sergiy Barlabanov created AMQ-4166:

             Summary: RedeliveryPlugin causes a deadlock with JobSchedulerImpl
                 Key: AMQ-4166
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.7.0
         Environment: Reproduced on Windows 8, Windows Vista, MacOS X
with Oracle jdk 1.7.0_07. ActiveMQ is started embedded using RAR inside Glassfish
            Reporter: Sergiy Barlabanov

Originates from the forum discussion

we have RedeliveryPlugin causing thread deadlock together with JobSchedulerImpl. ActiveMQ
version is 5.7.0. We activated RedeliveryPlugin in our broker config xml (see below). There
two stacktraces below as well. One is from ActiveMQ VMTransport thread, which tries to send
a message to a dead letter queue using RedeliveryPlugin. RedeliveryPlugin just tries to reschedule
the message for redelivery and for that it calls JobSchedulerImpl and blocks on its synchronized
method "schedule". On the way "consumersLock" is locked. 
Another stack trace is from JobScheduler:JMS thread, which fires a job to redeliver some message
and tries to send it using the same queue used by the VMTransport thread. And it blocks on
that consumersLock locked by the VMTransport thread. And this occurs in JobSchedulerImpl#mainLoop
method inside synchronized {} block causing a deadlock, since the VMTransport thread tries
to call another synchronized method of JobSchedulerImpl. The art how RedeliveryPlugin and
JobSchedulerImpl are programmed seems to be quite dangerous, since they both access the queues
and try to acquire queue locks. And additionally synchronized methods of JobSchedulerImpl
are called directly from RedeliveryPlugin making that to a nice source of thread deadlocks.
And I see no measures taken in the code to avoid these deadlocks.
We can reproduce it quite often if we start ActiveMQ with empty stores (kahadb and scheduler
stores are deleted manually from the file system before startup). But looking at the code,
I would say that the problem may occur in any situation in any deployment scenario (standalone
or embedded in a JEE container). It is just enough to have some Transport thread redelivering
a message and the JobScheduler thread trying to fire a job at the same moment on the same
And another strange thing, which is may be has nothing to do with the deadlock but is still
strange, is that according to the stack trace RedeliveryPlugin tries to redeliver an expired

Our broker configuration:

    <broker xmlns="" brokerName="dcdng" useJmx="true"
useShutdownHook="false" schedulerSupport="false">

            <managementContext createConnector="false"/>

            <kahaDB directory="${}" journalMaxFileLength="10mb"/>

            <transportConnector uri="${activemq.connector.address}"/>

                    <policyEntry queue=">" producerFlowControl="true"> 
                            <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true"
processExpired="false" enableAudit="false"/>

            <redeliveryPlugin fallbackToDeadLetter="true" sendToDlqIfMaxRetriesExceeded="true">
                            <redeliveryPolicy queue="EventQueue" maximumRedeliveries="10"

                            <redeliveryPolicy maximumRedeliveries="3" 

            <systemUsage sendFailIfNoSpace="true">
                    <memoryUsage limit="200 mb"/>
                    <storeUsage limit="1000 mb"/>
                    <tempUsage limit="200 mb"/>

Stack trace #1:

Name: ActiveMQ VMTransport: vm://dcdng#101-1 
State: BLOCKED on owned by:
Total blocked: 22  Total waited: 13 

   - locked java.lang.Object@7b97909e 
   - locked java.lang.Object@1b97b476 


Stack trace #2:

Name: JobScheduler:JMS 
State: WAITING on java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@30001430 owned
by: ActiveMQ VMTransport: vm://dcdng#101-1 
Total blocked: 15  Total waited: 480 
Stack trace: 
sun.misc.Unsafe.park(Native Method) 




   - locked 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message