[
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
