You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Izzy Alanis (JIRA)" <ji...@apache.org> on 2011/05/18 20:42:47 UTC
[jira] [Created] (AMQ-3327) Messages received after
unsubscribe/receipt using STOMP protocol.
Messages received after unsubscribe/receipt using STOMP protocol.
-----------------------------------------------------------------
Key: AMQ-3327
URL: https://issues.apache.org/jira/browse/AMQ-3327
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 5.5.0, 5.4.2
Reporter: Izzy Alanis
Priority: Critical
Using the STOMP transport, messages from a destination are sometimes being delivered *after* the receipt for unsubscribing from that destination is received.
In the following example, I subscribed to a queue witha prefetch size of 1, received a message, acknowledged it, then unsubscribed (with a receipt request), received the receipt for the unsubscription, and *then* received a message from the subscription that I just got the receipt for.
This is particularly problematic if, after unsubscribing from one queue, you want to subscribe to a different queue. Clients may (and will) mistakenly believe that the message they receive is from the new subscription, not the old one.
Clients can work around this issue by including subscription ids for all subscriptions, and adding client-side logic to ignore any messages received for non-active subscriptions.
This is a synchronization issue that may be difficult to reproduce in certain environments, but I was able to reproduce this issue in my test environment using a multi-threaded client that repeatedly subscribes, consumes messages and unsubscribes (with approximately a 1-in-5000 error rate).
Note that the client's expectations may be different for messages received *before* a unsubscribe receipt. Using the STOMP protocol, I expect to see messages for the subscription delivered until I unsubscribe. But I don't expect to see messages delivered after the unsubscribe is confirmed.
{quote}
SUBSCRIBE
destination:/queue/foo
ack:client
activemq.prefetchSize:1
id:dbbeded6-1182-4658-b076-10a064da31f5
MESSAGE
message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
destination:/queue/foo
timestamp:1305556042086
expires:0
subscription:dbbeded6-1182-4658-b076-10a064da31f5
priority:4
Test2 message (2952 of 5000)
ACK
message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
UNSUBSCRIBE
id:dbbeded6-1182-4658-b076-10a064da31f5
receipt:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
RECEIPT
receipt-id:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
MESSAGE
redelivered:true
message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2938
destination:/queue/foo
timestamp:1305556042085
expires:0
subscription:dbbeded6-1182-4658-b076-10a064da31f5
priority:4
Test2 message (2938 of 5000)
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-3327) Messages received after
unsubscribe/receipt using STOMP protocol.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3327.
-----------------------------
Resolution: Won't Fix
Working as designed.
> Messages received after unsubscribe/receipt using STOMP protocol.
> -----------------------------------------------------------------
>
> Key: AMQ-3327
> URL: https://issues.apache.org/jira/browse/AMQ-3327
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Izzy Alanis
> Priority: Critical
>
> Using the STOMP transport, messages from a destination are sometimes being delivered *after* the receipt for unsubscribing from that destination is received.
> In the following example, I subscribed to a queue witha prefetch size of 1, received a message, acknowledged it, then unsubscribed (with a receipt request), received the receipt for the unsubscription, and *then* received a message from the subscription that I just got the receipt for.
> This is particularly problematic if, after unsubscribing from one queue, you want to subscribe to a different queue. Clients may (and will) mistakenly believe that the message they receive is from the new subscription, not the old one.
> Clients can work around this issue by including subscription ids for all subscriptions, and adding client-side logic to ignore any messages received for non-active subscriptions.
> This is a synchronization issue that may be difficult to reproduce in certain environments, but I was able to reproduce this issue in my test environment using a multi-threaded client that repeatedly subscribes, consumes messages and unsubscribes (with approximately a 1-in-5000 error rate).
> Note that the client's expectations may be different for messages received *before* a unsubscribe receipt. Using the STOMP protocol, I expect to see messages for the subscription delivered until I unsubscribe. But I don't expect to see messages delivered after the unsubscribe is confirmed.
> {quote}
> SUBSCRIBE
> destination:/queue/foo
> ack:client
> activemq.prefetchSize:1
> id:dbbeded6-1182-4658-b076-10a064da31f5
> MESSAGE
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
> destination:/queue/foo
> timestamp:1305556042086
> expires:0
> subscription:dbbeded6-1182-4658-b076-10a064da31f5
> priority:4
> Test2 message (2952 of 5000)
> ACK
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
> UNSUBSCRIBE
> id:dbbeded6-1182-4658-b076-10a064da31f5
> receipt:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> RECEIPT
> receipt-id:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> MESSAGE
> redelivered:true
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2938
> destination:/queue/foo
> timestamp:1305556042085
> expires:0
> subscription:dbbeded6-1182-4658-b076-10a064da31f5
> priority:4
> Test2 message (2938 of 5000)
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3327) Messages received after
unsubscribe/receipt using STOMP protocol.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035583#comment-13035583 ]
Timothy Bish commented on AMQ-3327:
-----------------------------------
This isn't actually a bug. The Stomp 1.0 specification states that "Any client frame other than CONNECT may specify a receipt header with an arbitrary value. This will cause the server to acknowledge receipt of the frame with a RECEIPT frame which contains the value of this header as the value of the receipt-id header in the RECEIPT packet."
As stated the receipt header only acknowledges to the client that the broker has received the frame, not that its acted upon it in any way. You client will need to take into account the fact that messages are dispatched asynchronously and can and do sometimes arrive after you've sent the unsubscribe request.
> Messages received after unsubscribe/receipt using STOMP protocol.
> -----------------------------------------------------------------
>
> Key: AMQ-3327
> URL: https://issues.apache.org/jira/browse/AMQ-3327
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Izzy Alanis
> Priority: Critical
>
> Using the STOMP transport, messages from a destination are sometimes being delivered *after* the receipt for unsubscribing from that destination is received.
> In the following example, I subscribed to a queue witha prefetch size of 1, received a message, acknowledged it, then unsubscribed (with a receipt request), received the receipt for the unsubscription, and *then* received a message from the subscription that I just got the receipt for.
> This is particularly problematic if, after unsubscribing from one queue, you want to subscribe to a different queue. Clients may (and will) mistakenly believe that the message they receive is from the new subscription, not the old one.
> Clients can work around this issue by including subscription ids for all subscriptions, and adding client-side logic to ignore any messages received for non-active subscriptions.
> This is a synchronization issue that may be difficult to reproduce in certain environments, but I was able to reproduce this issue in my test environment using a multi-threaded client that repeatedly subscribes, consumes messages and unsubscribes (with approximately a 1-in-5000 error rate).
> Note that the client's expectations may be different for messages received *before* a unsubscribe receipt. Using the STOMP protocol, I expect to see messages for the subscription delivered until I unsubscribe. But I don't expect to see messages delivered after the unsubscribe is confirmed.
> {quote}
> SUBSCRIBE
> destination:/queue/foo
> ack:client
> activemq.prefetchSize:1
> id:dbbeded6-1182-4658-b076-10a064da31f5
> MESSAGE
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
> destination:/queue/foo
> timestamp:1305556042086
> expires:0
> subscription:dbbeded6-1182-4658-b076-10a064da31f5
> priority:4
> Test2 message (2952 of 5000)
> ACK
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
> UNSUBSCRIBE
> id:dbbeded6-1182-4658-b076-10a064da31f5
> receipt:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> RECEIPT
> receipt-id:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> MESSAGE
> redelivered:true
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2938
> destination:/queue/foo
> timestamp:1305556042085
> expires:0
> subscription:dbbeded6-1182-4658-b076-10a064da31f5
> priority:4
> Test2 message (2938 of 5000)
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira