activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AMQ-1878) Deadlock in broker can occur when optimised dispatch is true
Date Fri, 15 Aug 2008 14:29:52 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44971#action_44971
] 

rajdavies edited comment on AMQ-1878 at 8/15/08 7:29 AM:
----------------------------------------------------------

Fixed by SVN revision 685971 and revision 686236

      was (Author: rajdavies):
    Fixed by SVN revision 685971
  
> 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
>             Fix For: 5.2.0
>
>         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.


Mime
View raw message