Matthias,<br><font color="#888888"></font><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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:<br>
<br>
- we stay entirely within the defined protocol standard<br>
<br>
- the user can select the most appropriate matching logic with the
exchange type, rather than being constrained to topic-based matching</blockquote><div><br>I'll take a look at this when I get a chance, sounds like a decent idea to me.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- 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.<font color="#888888"><br>
</font></blockquote></div><br>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.<br>
<br>Martin, <br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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?<font color="#888888"></font></blockquote>
<div><br>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.<br>
<br>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.<br>
</div></div><br>Kyle<br>