You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2011/05/20 15:12:47 UTC
[jira] [Closed] (AMQ-3327) Messages received after
unsubscribe/receipt using STOMP protocol.
[ 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