[rabbitmq-discuss] Simpler STOMP Behaviour
lionel.cons at cern.ch
Tue Oct 5 08:07:06 BST 2010
Michael Bridgen <mikeb at rabbitmq.com> writes:
> 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)
In practice, other solutions exist. I'm not sure which one is
(1) With ActiveMQ, one can subscribe to /temp-queue/whatever and a
private queue with a random name will be created on the broker. The
client program can send a message to itself, examine the destination
header of the received message and find out this way what is the real
(2) We could imagine using the RECEIPT frame to allow the broker to
"reply" to the client. Something like:
> SUBSCRIBE /reply/<md5 of some client properties>
This would work too.
>> 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?
For instance. AMQP 1.0 has nodes, queues, links and filters (and no more
exchanges). They should be exposed via STOMP somehow.
In addition, AMQP 1.0 introduced the notion of global addressing,
something like node-name at container. This should also be usable from
However, I'm not up-to-date with what AMQP 1.0 really is today. Concepts
like remote addressing have been described for instance in last year's
I don't know if these are still relevant...
More information about the rabbitmq-discuss