[rabbitmq-discuss] New exchange type

Wed Apr 23 04:19:47 BST 2008

Matthias,

It occurred to me that rather than introducing a new exchange type one could
> place an indicator in the exchange arguments that turns any exchange from a
> multicast to an anycast exchange. That has two advantages:
>
> - we stay entirely within the defined protocol standard
>
> - the user can select the most appropriate matching logic with the
> exchange type, rather than being constrained to topic-based matching

I'll take a look at this when I get a chance, sounds like a decent idea to
me.

- use a flag in the process dictionary to indicate whether the random number
> generator has been seeded. Check/set that flag in your current code that
> invokes random:uniform. This has the same effect as the previous approach
> but is a less intrusive change since you don't need to touch any other
> modules.
>

Got this working, and less intrusive wins out in my mind. I'll send out
another version of the diff when I get to the above change, or if I leave
that on the back burner for too long.

Martin,

I've seen this requirement before, however, AFAICS it breaks AMQP model. The
> exchanges are meant to be used for message distribution, i.e. the message
> should be delivered to *all* queues with appropriate binding to the
> exchange. Queues are intended to do the load-balancing. Not adhering to this
> model causes problems with some more sophisticated use cases (wire-tapping,
> federation). It also introduces a lot of unfairness to the load-balancing
> algorithm. Why do you believe a single queue would create a significantly
> graver bottleneck when compared to a single exchange?

>From what I could tell from the RabbitMQ docs,  even if I have a single
exchange, messages can be routed through any node in the cluster. Therefore
there should be no significant bottleneck with a single exchange, because
there is no single node that all messages must go through. With a single
queue, however, every message has to be sent to the machine on which that
queue lives, after which different subscribers can pull messages off. This
looks like a bottleneck to me, where all messages go through one machine,
whereas a single exchange does not have that problem (unless I missed
something). I'd love to have the queues do the load balancing, but as we're
dealing with commodity hardware (EC2), having a single machine handle all
our messages is a significant problem.

As to the other concern, clearly there are some use cases of AMQP that this
will not work for. We're using RabbitMQ for pub-sub style message
distribution as well as the requirement this change handles, and for
simplicity we would like to use the same technology (and implementation) to
satisfy both requirements.

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080422/952f9a2b/attachment.htm 