[rabbitmq-discuss] Stomp: after deleting a durable subscription, message is still available

[Steve Powell]

Michael,
Thank you for pointing this out.  In reproducing your results I noticed that I get an error when UNSUBSCRIBE is issued. So that explains why you were still seeing the messages after issuing the UNSUBSCRIBE.

Before a session can cancel a subscription it needs to know about it -- that is what the id is for.

The STOMP 1.1 specification says this about subscription ids:
SUBSCRIBE id Header

An id header MUST be included in the frame to uniquely identify the subscription within the STOMP connection session. Since a single connection can have multiple open subscriptions with a server, the id header allows the client and server to relate subsequent ACK, NACK or UNSUBSCRIBEframes to the original subscription.

and the phrase "uniquely identify the subscription within the STOMP connection session" is the problem.  That implies that the id is *limited in scope* to the session.

In the case of durable subscriptions, as soon as you disconnect your subscription id is no longer in scope.  Reconnecting and using the same id ought to give you a distinct session and therefore a distinct subscription.  But then, what good is a durable subscription if you can never refer to it again??

The solution as adopted in the RabbitMQ STOMP adapter is to make the id on the subscription non-local.  That is, we make it global to the RabbitMQ server.  (Actually, as implied in the RabbitMQ/stomp documentation, we make the *combination of subscription id and (topic) destination* global to the server.)  This means that SUBSCRIBE is the way to reconnect to the same subscription-id x topic, and then you can UNSUBSCRIBE from it (and delete it) successfully.

[Notice what this means: the messages that were sitting "in the topic" for that subscription id are never discarded completely: in order to remove them you must SUBSCRIBE first -- and they are then delivered to you of course.  This is quite a nice 'feature', IMO.]

I think you might have been aware of this, since you used the header "client-id" on your CONNECT frames.  This is not a STOMP header, but might be an ActiveMQ one.  It is not clear to me what the full effect of this header is, but it appears to identify a session context for subscription ids (at least). I notice that when the "durable client" reconnected, the subscriptions were not re-instated (no messages arrived) -- is that what you would expect ActiveMQ to do?

I will raise a bug (we will probably try to behave compatibly with ActiveMQ), and take this up with the STOMP spec group.

Steve Powell
steve at rabbitmq.com
[wrk: +44-2380-111-528] [mob: +44-7815-838-558]

On 6 Sep 2011, at 19:28, Michael Justin wrote:
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-September/014915.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110909/3fb7d51b/attachment.htm>