[
https://issues.apache.org/jira/browse/IMAP-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633893#comment-13633893
]
Andrzej Rusin commented on IMAP-372:
------------------------------------
Eric,
It's the jstack tool from standard Sun/Oracle JDK. It identifies and shows the
deadlock (probably depending on command line arguments) when it exists.
I believe it can be done manually too, by looking at what threads obtained any
locks and what threads are waiting for them. If there is a loop in the graph
constructed from these dependencies, then there is a deadlock.
> Deadlock in AbstractDelegatingMailboxListener under load
> --------------------------------------------------------
>
> Key: IMAP-372
> URL: https://issues.apache.org/jira/browse/IMAP-372
> Project: James Imap
> Issue Type: Bug
> Components: Mailbox
> Reporter: Andrzej Rusin
> Assignee: Eric Charles
> Attachments: James Listener Deadlock.txt
>
>
> In AbstractDelegatingMailboxListener::event, firing the events inside the
> synchronized blocks causes a deadlock involving:
> lock on HashMapDelegatingMailboxListener::listeners
> (synchronized methods) lock on SelectedMailboxImpl
> In my example, these 3 methods got interlocked:
> AbstractDelegatingMailboxListener.addListener
> SelectedMailboxImpl.msn
> AbstractDelegatingMailboxListener.removeListener
> My idea to fix it is basically to take the for loop on mListeners outside the
> synchronized block in
> org.apache.james.mailbox.store.AbstractDelegatingMailboxListener.event(Event).
> That will not make the propagated event processing in SelectedMailboxImpl
> hit the synchronized lock on listeners.
--
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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
