[
https://issues.apache.org/jira/browse/AMQ-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094703#comment-16094703
]
Timothy Bish commented on AMQ-6773:
-----------------------------------
This is unlikely to change as there are several restrictions on the behavior of
a MessageConsumer and it's parent session in regards to how they should behave
when a MessageConsumer is doing asynchronous delivery. It's likely the
offending code is misusing the client code in a non-JMS compliant manner.
I'd recommend you attach information on the deadlock to this issue for
analysis, but I am quite doubtful that we'd ever remove that locking, it's
quite a common pattern for JMS clients to use.
> Calling external code while holding a lock sometimes results in deadlock
> ------------------------------------------------------------------------
>
> Key: AMQ-6773
> URL: https://issues.apache.org/jira/browse/AMQ-6773
> Project: ActiveMQ
> Issue Type: Bug
> Reporter: Tim Bain
>
> A user reports that multiple different deadlocks have occurred when ActiveMQ
> is run in the context of a Mule application, due to our invoking the
> ActiveMQMessageConsumer.onMessage() method (which can eventually call
> external code) while holding a lock.
> http://activemq.2283324.n4.nabble.com/Fwd-Deadlock-caused-by-ActiveMQMessageConsumer-dispatch-due-to-onEvent-invocation-td4723587.html
> has the details of what occurred, as he has described it.
> Since one of the prime rules for avoiding deadlocks is to avoid invoking
> external code while holding locks, we should figure out how to invoke
> onMessage() at a time when we don't hold the lock, while still protecting
> ourselves from whatever race conditions could occur if we concurrently
> invoked more than one of the methods protected by the lock.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
