<div dir="ltr">Hmmm... I just realized that the proposed configuration of setting things up in a ring will have one other adverse affect (besides weakening HA). �<div><br></div><div style>If I have the ring setup like this: �A --> B --> C --> A... then if B and C both have worker queues for the same type of task, B will tend to get too much preference because it will handle all requests from A and B (since the requests will never go to the AE to route to C)-- whereas the ideal setup would equally distribute requests from A to B and to C. �Hmmm...</div>
<div style><br></div><div style>Is there any ongoing work to make RabbitMQ support a feature more like ActiveMQ's network of brokers? �In ActiveMQ's network of brokers, I think it truly operates as one logical bus (still giving preference to local consumers)-- which seems more like what I want. �(That said, I have heard a few horror stories about ActiveMQ's network of brokers too.)</div>
<div style><br></div><div style>Thanks,</div><div style>Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 12:13 PM, Chris <span dir="ltr"><<a href="mailto:stuff@moesel.net" target="_blank">stuff@moesel.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Simon,<div><br></div><div>Thanks for the suggestions. �This definitely gets me closer to what I'm looking for! �I didn't know about the alternate-exchange, so that's very helpful to know (and could be helpful in other scenarios too). �The ring-configuration sounds like it could work too, but then I guess I am giving up some high availability-- in that a single broken link breaks the chain and potentially prevents communication to other brokers that are still running fine.</div>
<div><br></div><div>Definitely something to think about. �Thanks, Simon!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 10:10 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 18/12/12 13:55, Chris wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a federation of brokers (let's say two: A and B). �They are<br>
federated because they are across WAN, so I know clustering will not<br>
work. �I would like to setup worker queues so that if I submit a job to<br>
an exchange/queue, it will be processed by one and only one consumer<br>
across the federated brokers. �Ideally, it should also prefer local<br>
consumers before going to federated consumers.<br>
<br>
For example:<br>
<br>
Broker A: Workers listening on queues with routing keys X & Y<br>
Broker B: Workers listening on queues with routing keys Y & Z<br>
<br>
1) Submit job with routing key X from Broker A: Should go to Consumer of<br>
X on Broker A<br>
2) Submit job with routing key Y from Broker A: Should go ONLY to<br>
Consumer of Y on Broker A<br>
3) Submit job with routing key Z from Broker A: Should go to Consumer of<br>
Z on Broker A<br>
</blockquote>
<br></div>
I think that the alternate-exchange mechanism (<a href="http://www.rabbitmq.com/ae.html" target="_blank">http://www.rabbitmq.com/ae.<u></u>html</a>) might help you here. Publish to a non-federated direct exchange X1. Declare X1 with an AE of a federated direct exchange: X2.<br>
<br>
Your workers will need to bind to both X1 and X2 unfortunately, but messages should get routed the way you want - if there's a local binding then the message never hits the federated exchange, but if there isn't it then goes out over federation.<br>
<br>
What this *won't* do is ensure the message only gets delivered to *one* other broker over federation. Aha! But you could do that by making each X1 be federated, but have its upstream set to a single remote X2, with the broker federation links arranged in a ring. Then messages go round the ring, at each node either being delivered locally or forwarded on by federation. You'd need to set max_hops to the ring size at each point, so that unroutable messages go round the ring once and then die.<br>
<br>
Does this make sense?<br>
<br>
Cheers, Simon<span><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>