[rabbitmq-discuss] STOMP plugin - durable subscription limitation

Fri Oct 19 14:22:29 BST 2012

Hi Michael,

On 18/10/12 17:11, Michael Justin wrote:
> However, RabbitMQ uses the id header differently for topic 
> subscriptions. Sending and receiving requires to set the same value, so 
> that consumers are not able to assign any random identifier in the 
> SUBSCRIBE frame. Is this correct so far and as designed?

Consumers are able to assign arbitrary values in the id header when
subscribing with any kind of destination, precisely for the reason that
you need: so that messages delivered for that subscription can be
matched up.

Unless I'm misunderstanding your question, your examples even show that
this works. The subscriptions with id
{F09BD8A4-0C7B-4830-B4B5-B3F5D76E5A7C} has messages delivered with the
same value in the subscription: header. Likewise with the subscription
containing "durable-subscription-name" as the value of the id header.
The delivered message has "durable-subscription-name" in the
subscription header so that the client can match the message up with the
subscription.

> This has the effect that a client can not handle more than one consumer 
> for the same durable subscription because a SUBSCRIBE frame can not use 
> a client-side assigned identifier in the same way and use it to route 
> incoming messages based on this id between internal 'consumers'.

This is what the "id:" and "subscription:" headers were designed for.

> Example:
> 
> 2. RabbitMQ with durable subscription
> 
> SUBSCRIBE
> destination:/topic/TOOL.DEFAULT
> receipt:yes
> ack:auto
> id:durable-subscription-name

This value ^

> persistent:true
> 
> received:
> MESSAGE
> receipt:receipt
> persistent:true
> content-type:text/plain
> subscription:durable-subscription-name

is the same as this one ^

> destination:/topic/TOOL.DEFAULT
> message-id:T_durable-subscription-name@@session-whuoJn95NxH3Ic-lQIr-Wl@@1
> content-length:9

> The STOMP 1.0 specification says:
> 
> "You can also specify an id header which can then later on be used to 
> UNSUBSCRIBE from the specific subscription as you may end up with 
> overlapping subscriptions using selectors with the same destination."

As far as I can see RabbitMQ fully adheres to the spec, which also says
of MESSAGE frames: "The subscription header will be set to match the id
header of the subscription that is receiving the message".

> In RabbitMQ however, overlapping subscriptions seem to be impossible for 
> a durable topic, as there is no way to specify unique values for the id. 
> Is this correct?

If I'm misunderstanding your question then please send another
illustration that shows what information is missing. Is the problem with
the STOMP spec or with the RabbitMQ implementation of it?

-Emile