[ 
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)

Reply via email to