[
https://issues.apache.org/jira/browse/AMQ-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Gerhardsson updated AMQ-4022:
-------------------------------------
Description:
Executive summary
---
A message is lost, the connection ends up in a strange state, and then when the
client sends DISCONNECT it gets no receipt.
Details
---
Steps to reproduce:
1) 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.
4) Wait 10ms for message
5) Go right ahead and send DISCONNECT message, asking for a receipt.
5.1) About 20% of the time, no DISCONNECT receipt is received, however long the
client waits. This seems to coincide with the case when the message doesn't
arrive in #4.
5.2) It does look like ActiveMQ gets the DISCONNECT message tho since it
unsubscribes the client from /topic/foo at that timestamp.
The DISCONNECT receipt getting lost is clearly a bug. Waiting for the receipt
is important since I've seen cases where the client isn't unregistered properly
in ActiveMQ if the client just sends DISCONNECT and then closes the socket.
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 occured again.
was:
Executive summary
---
A message is lost, the connection ends up in a strange state, and then when the
client sends DISCONNECT it gets no receipt.
Details
---
Steps to reproduce:
1) 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.
4) Wait 10ms for message
5) Go right ahead and send DISCONNECT message, asking for a receipt.
5.1) About 20% of the time, no DISCONNECT receipt is received, however long the
client waits. This seems to coincide with the case when the message doesn't
arrive in #4.
5.2) It does look like ActiveMQ gets the DISCONNECT message tho since it
unsubscribes the client from /topic/foo at that timestamp.
The DISCONNECT receipt getting lost is clearly a bug. Waiting for the receipt
is important since I've seen cases where the client isn't unregistered properly
in ActiveMQ if the client just sends DISCONNECT and then closes the socket.
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 test runs with the script
the error occured again.
> SEND directly after SUBSCRIBE causes bad state -> no DISCONNECT receipt
> -----------------------------------------------------------------------
>
> 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
> Attachments: amqtest.pl, Net_Stomp.pm.diff
>
>
> Executive summary
> ---
> A message is lost, the connection ends up in a strange state, and then when
> the client sends DISCONNECT it gets no receipt.
> Details
> ---
> Steps to reproduce:
> 1) 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.
> 4) Wait 10ms for message
> 5) Go right ahead and send DISCONNECT message, asking for a receipt.
> 5.1) About 20% of the time, no DISCONNECT receipt is received, however long
> the client waits. This seems to coincide with the case when the message
> doesn't arrive in #4.
> 5.2) It does look like ActiveMQ gets the DISCONNECT message tho since it
> unsubscribes the client from /topic/foo at that timestamp.
> The DISCONNECT receipt getting lost is clearly a bug. Waiting for the receipt
> is important since I've seen cases where the client isn't unregistered
> properly in ActiveMQ if the client just sends DISCONNECT and then closes the
> socket.
> 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 occured 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
