[rabbitmq-discuss] Simpler STOMP Behaviour
mikeb at rabbitmq.com
Mon Oct 4 16:27:01 BST 2010
>> This design proposes to remove the custom headers, and use only the
>> `destination` header with compound values that define the exchange,
>> routing key and queue names.
> This looks very good.
> There is one additional use case which is often needed: private
> temporary queues to get replies back. This maps to the Return Address
> concept in Enterprise Integration Patterns.
> Is this something that could be done with your proposed syntax?
Since there's no reply from the server to SUBSCRIBE, and we generally
want reply queues to have different properties to shared queues, really
the only option is to have a distinguished prefix for reply queue
destinations, and require clients to supply their own (preferably fresh)
SUBSCRIBE /reply/<md5 of some client properties>
It might be an idea to use queue leases for these, instead of
auto-delete, so that a client fronting up after a connection drop has a
chance of recovering replies. (If it's lost its own state, then it
should construct a fresh name)
> Also, what about AMQP 1.0? Have you considered it in order to get a
> syntax that can be adapted/extended to the new AMQP 1.0 concepts?
Do you mean using something like /node/ for destinations?
There aren't really any such concepts in AMQP 1.0 to pin a concrete
protocol implementation to. It's only a message exchange protocol, and
just like STOMP, doesn't take an opinion on what is addressable at the
broker. Indeed, if we were to make an AMQP 1.0 adapter, we'd have to
invent some scheme for addressing exchanges and queues there, too.
More information about the rabbitmq-discuss