You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Facundo Velazquez (JIRA)" <ji...@apache.org> on 2017/07/20 13:40:00 UTC
[jira] [Commented] (AMQ-6773) Calling external code while holding a
lock sometimes results in deadlock
[ 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)