[
https://issues.apache.org/jira/browse/AMQ-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-4022.
-------------------------------
Resolution: Fixed
Fix Version/s: (was: NEEDS_REVIEWED)
5.8.0
This was fixed before the v5.6.0 release and is no longer an issue, the code
has been refactored to avoid this particular deadlock scenario. Upgrade to a
newer broker version and you won't run into this any longer.
> Receiving event while disconnecting -> AMQ deadlock -> "Already connected"
> error
> --------------------------------------------------------------------------------
>
> Key: AMQ-4022
> URL: https://issues.apache.org/jira/browse/AMQ-4022
> Project: ActiveMQ
> Issue Type: Bug
> Components: stomp
> Affects Versions: 5.5.1
> Environment: SLES11-SP1 x86_64
> Reporter: Gabriel Gerhardsson
> Assignee: Timothy Bish
> Fix For: 5.8.0
>
> Attachments: AMQ_4022_possible_fix.diff, amqtest.pl, Net_Stomp.pm.diff
>
>
> Executive summary
> ---
> When an event is about to be delivered to a client while that client
> simultaneously sends a DISCONNECT message, there's a risk for a deadlock
> between two threads in ActiveMQ, causing no DISCONNECT receipt as well as
> "Already connected" error if another client connects with the same client ID.
> Details
> ---
> Here's steps to reproduce, using STOMP, tho it's possible that this issue
> exists for other protocols also, since the deadlock happens in
> broker/TransportConnection.java. I could reproduce the error easily with
> these steps, tho it's entirely possible that some of the steps aren't
> strictly required but rather provides certain needed timing.
> 1) Connect to ActiveMQ using STOMP
> 2) Send a SUBSCRIBE message with destination=/topic/foo, without asking for a
> receipt. No other options sent in message.
> 3) Send a message to /topic/foo, without asking for a receipt. Note: It's
> important that the message is auto-acked by the server.
> 4) Wait 10ms for message
> 5) Go right ahead and send DISCONNECT message, asking for a receipt.
> 5.1) About 20% of the time, the message is never received, nor is the
> DISCONNECT receipt.
> 5.2) Run 'jstack -p <activemq pid>', watch how the JVM prints info on stdout
> about a deadlock between two threads.
> Test script
> ---
> Apply the small patch to the perl library Net/Stomp.pm
> It's a naive minimal patch to make it wait for a receipt for the DISCONNECT
> message. It will actually just wait for any frame to arrive and won't check
> what it is, but it's enough for this test.
> Run amqtest.pl a few times. A non-buggy run completes almost immediately. A
> buggy run hangs the script during disconnect.
> Workaround
> ---
> -When sending the SUBSCRIBE with receipt requested, and waiting for the
> receipt before sending the SEND, I was unable to reproduce the issue, even
> after running the script 100000 times.-
> No, it turns out that the workaround suggested above does not completely
> eliminate the problem. It probably just introduces a large enough delay to
> almost always avoid the race condition. After 30000 additional test runs with
> the script the error occurred again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
