<div dir="ltr">Hi Simon,<div><br></div><div style>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 style><br></div><div style>Definitely something to think about. Thanks, Simon!</div><div style><br></div><div style>-Chris</div></div><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 class="im">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 class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>