[
https://issues.apache.org/jira/browse/AMQ-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094701#comment-16094701
]
Facundo Velazquez commented on AMQ-6773:
----------------------------------------
Hi [~tbain98].
This deadlock was reproduced with ActiveMQ 5.13.0 version, but probably It
happens in last version yet.
I am attaching stacktraces for that you can analyze them, here:
https://drive.google.com/open?id=0B86KUpMySyxRRFNzVTAtSHFva0U.
According to the stacktrace, ActiveMQ locks that take place in the issue are in
the following lines:
https://github.com/apache/activemq/blob/master/activemq-client/src/main/java/org/apache/activemq/ActiveMQMessageConsumer.java#L1404
(This code line calls calls our code without releasing the acquired lock for
dispatching the JMSMessage)
and
https://github.com/apache/activemq/blob/master/activemq-client/src/main/java/org/apache/activemq/FifoMessageDispatchChannel.java#L133
(This code line is called by Mule to close the connection in a Reconnection
Strategy case).
In the Spring side, Lock that takes place in the issue is in the following line:
https://github.com/spring-projects/spring-framework/blob/master/spring-jms/src/main/java/org/springframework/jms/connection/SingleConnectionFactory.java#L318
If you need more information, please let me know.
> 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)