[rabbitmq-discuss] STOMP doesn't include the routing-key on MESSAGE frames

Tony Garnock-Jones tonygarnockjones+rabbitmq at gmail.com
Mon Feb 20 19:56:16 GMT 2012

Hi Steve,

On 20 February 2012 12:04, Steve Powell <steve at rabbitmq.com> wrote:
> Sorry I was so long in replying.

Thanks for getting back to me!

> When you say 'no longer propagated', you imply that we used to do this. I guess
> that was in the original implementation? :-)

It was, yep.

> There is really no limit to the amount of information we could include in the
> MESSAGE headers gleaned from the underlying implementation. We could easily
> provide the AMQP exchange-name, consumer-tag and delivery-tag.

You already do, or at least you give equivalents. The destination
perforce covers the exchange name; the consumer-tag is covered by the
"subscription" header in MESSAGE; and the delivery-tag is covered by
"message-id". What's missing is the small gap between the concrete
destination to which the message was sent and the abstract destination
(really, a destination pattern) used in the SUBSCRIBE. And that gap
is, in AMQP, covered exactly by the routing-key. Think of it as the
bindings from unification of the destination from subscribe with the
destination from publish (erm, if you imagine the
subscription-destination-pattern to be a regex, it's kind of the
capture groups).

Adding the routing_key puts the final small missing piece in place. A
perhaps more STOMPish way of giving it would be to have a "to" header
or similar carried in a MESSAGE, containing the full destination given
in the SEND. Oh wait! I've just checked, and actually that's what's
required by the 1.1 spec already. So the STOMP adapter isn't quite
spec-compliant, in that it's giving the destination from the
*subscribe* rather than the *send*.

(This makes sense, actually: the server needn't repeat the SUBSCRIBE's
destination header in each MESSAGE, as the client after all was the
one that specified it in the SUBSCRIBE! Carrying the SEND's
destination into the MESSAGE genuinely tells the consuming client
something they can't know in advance.)

> The meaning and content of the header
> value might change as we change our mapping.

I don't care about that: I just want the routing key, because I'm
using STOMP for simple interop with real AMQP clients.

> So, I'm reluctant to include this information unless there is a compelling STOMP
> reason for doing so. Is your application a pure STOMP one?

No: that's why the routing_key is important.

Tony Garnock-Jones
tonygarnockjones at gmail.com

More information about the rabbitmq-discuss mailing list