You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Rob Davies (JIRA)" <ji...@apache.org> on 2008/08/14 19:41:52 UTC
[jira] Assigned: (AMQ-1878) Deadlock in broker can occur when
optimised dispatch is true
[ https://issues.apache.org/activemq/browse/AMQ-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-1878:
-------------------------------
Assignee: Rob Davies
> Deadlock in broker can occur when optimised dispatch is true
> ------------------------------------------------------------
>
> Key: AMQ-1878
> URL: https://issues.apache.org/activemq/browse/AMQ-1878
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.1.0
> Reporter: David Sitsky
> Assignee: Rob Davies
> Priority: Critical
> Attachments: deadlock.txt, queue.patch
>
>
> As an experiment in my application, I set optimised dispatch to be true for the broker and discovered during the startup of my application, a deadlock could occur. The problem is the classic lock hierarchy issue, one thread has asked for lock A then B, another has asked for lock B then A.
> I've attached an annotated jstack output with just the deadlock information, annotated with the locks involved. I have also added a patch which seems to resolve the issue, but I can't be sure if the change has other ramifications.
> The problem in a nutshell is one thread calls Queue.addSubscription(), which locks dispatchLock, and then calls wakeup/iterate() which blocks on iteratingMutex.
> Another thread meanwhile has called Queue.send(), which locks iteratingMutex via wakeup/iterate(), but then tries to call doPageIn() which requires dispatchLock.
> It seems to me addSubscription() doesn't need to hold on to dispatchLock while calling wakeup/iterate(), so I moved the wakeup() outside the usage of dispatchLock. This ensures the lock heirarchy between iteratingMutex and dispatchLock is always obtained in the same order. removeSubscription() has the same issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.