[rabbitmq-discuss] Simpler STOMP Behaviour
mikeb at rabbitmq.com
Tue Oct 5 12:36:07 BST 2010
On 10/05/2010 08:07 AM, Lionel Cons wrote:
> 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
> queue name.
I don't quite understand this -- when sending the tracer message, does
the client also use "/temp-queue/whatever" as the destination; and if
that works, why bother finding out the "real" queue name?
> (2) We could imagine using the RECEIPT frame to allow the broker to
> "reply" to the client. Something like:
> SUBSCRIBE /i-want-a-private-queue
Ah, RECEIPT, good call. I was wrong about the server no being able to
reply. This would be my preferred style; with the following as a option
>> 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.
Not any more; queues are mentioned only in passing if at all. And nodes
really are just a stand-in something for addresses to be addressing.
Links are an abstraction in the transfer protocol rather than part of a
It's not true to say there are "no more exchanges" in the sense that
AMQP 1.0 somehow does away with the exchange/binding/queue model. The
recommendation sets out a message transfer protocol, and tries very hard
to not take any position on where messages are when they are not being
transferred. So it's not the case that the AMQP 1.0 recommendation
supplants the broker model given in previous versions of AMQP with
something else (nodes, links, whatever) -- it simply steers clear of
saying anything about a broker model.
> In addition, AMQP 1.0 introduced the notion of global addressing,
> something like node-name at container. This should also be usable from
This was mooted at some point but doesn't actually appear in the
recommendation, which says next to nothing about the form of addresses.
It may still come about, in some ancillary part of the specification.
> 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
> F2F meeting:
> I don't know if these are still relevant...
If you want to catch up it is worth reading the recommendation; it's
significantly different to the previous most long-lived revision (PR2)
which was itself something of a departure from earlier revisions.
More information about the rabbitmq-discuss