activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] [Commented] (AMQ-3327) Messages received after unsubscribe/receipt using STOMP protocol.
Date Wed, 18 May 2011 18:56:48 GMT


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:
>             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}
> destination:/queue/foo
> ack:client
> activemq.prefetchSize:1
> id:dbbeded6-1182-4658-b076-10a064da31f5
> 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)
> message-id:ID:localhost-61955-1305208152844-4:617:-1:1:2952
> id:dbbeded6-1182-4658-b076-10a064da31f5
> receipt:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> receipt-id:1d2a8486-ee7a-48ba-842c-d0c47c1be5be
> 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:

View raw message