You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "J Moran (JIRA)" <ji...@apache.org> on 2008/07/11 19:58:00 UTC
[jira] Created: (AMQ-1856) Deadlock in AMQMessageStore when using
transactions
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
Priority: Blocker
Attachments: 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.
[jira] Assigned: (AMQ-1856) Deadlock in AMQMessageStore when using
transactions
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (AMQ-1856) Deadlock in AMQMessageStore when using
transactions
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-1856.
-----------------------------
Fix Version/s: 5.2.0
Resolution: Fixed
Fixed by SVN revision 676636
> 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
> Fix For: 5.2.0
>
> 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.
[jira] Updated: (AMQ-1856) Deadlock in AMQMessageStore when using
transactions
Posted by "J Moran (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
J Moran updated AMQ-1856:
-------------------------
Attachment: AMQ-1856.patch
Perhaps the patch is as simple as this? Mirrors behaviour of addMessage.
> 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
> 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.