[rabbitmq-discuss] Message Aggregating Queue
tim at rabbitmq.com
Thu Apr 28 16:42:17 BST 2011
On 28/04/11 15:56, Tony Garnock-Jones wrote:
> On 28 April 2011 10:32, Alvaro Videla <videlalvaro at gmail.com
> <mailto:videlalvaro at gmail.com>> wrote:
> do you think is a good idea to specify backing queue
> implementation during 'queue.declare'?
> It seems to me like it's /very/ clearly the Right Thing to do.
> Exchanges and queues are similar in a lot of ways; in particular, they
> can be seen as special cases of a more general kind of lump of
> functionality, so being able to specify exchange types is a clue that
> being able to specify queue types might also be useful.
Going further, I think it makes sense to allow things other than queues
to be bound into exchanges.
The only thing that really matters is the thing that's bound into the
exchange can accept a message. What it does with the message afterwards
(queues it, puts it in a map, or whatever) the exchange doesn't need to
FWIW, this was actually at the core of the design of HornetQ when I was
doing that. In some ways the HQ model is similar to AMQP 0.8/0.9.x,
there is a concept of an postoffice (which is similar to an exchange),
then things called "bindings" are bound into the exchange using a
specific key (binding key). Binding is just an interface which accepts a
message (or not).
Concrete binding types are Queue (which is like an AMQP queue only more
a bit more sophisticated - (it supports message selectors, priorities
etc), LVQ, and Divert - this takes a message and re-routes back through
the postoffice under a different routing key, it can also copy a message
and "siphon" it off elsewhere. You can also create your own and add them
to the postoffice.
Anyway, the point is you can do some really sophisticated things when
you combine exchanges and "things that accept messages" rather than just
exchanges and queues.
> More generally, AMQP in some sense wants to be a model of a
> named-soup-of-objects-in-the-broker (hence AMQP 1.0's approach, as I
> understand it), so from this point of view having named classes
> (fanout exchange, direct exchange, queue-backed-by-rabbit,
> queue-backed-by-riak, etc) and as generic a factory/constructor method
> as possible (in 0-9-1 unavoidably split into at least exchange.declare
> and queue.declare) makes a fair bit of sense.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss