[
https://issues.apache.org/activemq/browse/AMQ-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies reassigned AMQ-1856:
-------------------------------
Assignee: Rob Davies
> Deadlock in AMQMessageStore when using transactions
> ---------------------------------------------------
>
> Key: AMQ-1856
> URL: https://issues.apache.org/activemq/browse/AMQ-1856
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.1.0
> Environment: Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
> jdk1.6.0_07
> Reporter: J Moran
> Assignee: Rob Davies
> Priority: Blocker
> Attachments: AMQ-1856.patch, thread_dump.txt
>
>
> I am using ActiveMQ 5.1.0 with the AMQMessageStore (in the default
> configuration except data directory location) and sending/receiving
> transactionally using the VMTransport. This produced the deadlock shown in
> the attached (partial) thread dump, generated by jstack -l.
> In a nutshell, the VMTransport thread is holding the
> AMQMessageStore.lock=KahaReferenceStore.lock, acquired at
> AMQMessageStore.java:231, while awaiting a countDown on
> AMQMessageStore.flushLatch. The ActiveMQ Task (which is the
> AMQMessageStore.asyncWriteTask) should do the countDown on the flushLatch but
> is waiting on acquiring the KahaReferenceStore.lock first. Hence deadlock.
> Note that the condition messageAcks.size() >
> this.peristenceAdapter.getMaxCheckpointMessageAddSize() must be true for the
> deadlock to occur -- this triggers the flush.
> Since the transport is one of the deadlocked threads, all access via the
> transport stops, making the broker unusable and making this issue a blocker
> for me. A comment (workaround?) as soon as possible would be much appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
