activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (AMQ-3327) Messages received after unsubscribe/receipt using STOMP protocol.
Date Fri, 20 May 2011 13:12:47 GMT

     [ 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

Mime
View raw message