[ 
https://issues.apache.org/jira/browse/AMQ-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355894#comment-17355894
 ] 

ASF subversion and git services commented on AMQ-8287:
------------------------------------------------------

Commit ac27cc2cda1ac10d01bc87c1f875dcf278a9594f in activemq's branch 
refs/heads/main from Christopher L. Shannon (cshannon)
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ac27cc2 ]

Merge branch 'AMQ-8287' into main

This closes #666


> Deadlock caused by synchronized on serviceRead() in NIOSSLTransport
> -------------------------------------------------------------------
>
>                 Key: AMQ-8287
>                 URL: https://issues.apache.org/jira/browse/AMQ-8287
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.15.15, 5.16.2
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>            Priority: Major
>             Fix For: 5.17.0, 5.16.3
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I ran into a deadlock caused by the fix for AMQ-8169 when using Stomp 
> NIOSSLTransport (but it could probably happen for other nio ssl transports)
> The newly added synchronized on the serviceRead() caused a deadlock between 
> the transport and the TransportConnection. One thread acquired a lock on the 
> TransportConnection and was waiting on serviceRead() to acquire the 
> NIOSSLTransport lock. Another thread had was inside serviceRead() so it 
> acquired the NIOSSLTransport lock and was then later waiting for the 
> TransportConnection lock.
> The main issue is that processCommand(plain) ends up being protected by the 
> lock and since there's multiple brokers/filters running we run into a 
> deadlock (my current deadlock happened processing a ConsumerInfo command)
> To fix this we simply need to narrow the lock as it's too broad. The goal 
> here was to protect the the reading off the channel concurrently (so really 
> the secureRead() method so we can move the lock to secureRead() and not lock 
> the entire serviceRead() call and that should fix the deadlock problem while 
> still solving the initial issue which was demonstrated by the StompNIOSSL 
> failing before this fix. I will open a new Jira shortly and push a fix.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to