<div dir="ltr">Hi Matthias,<div><br></div><div style>Thanks for your reply. �I too originally preferred to go with the simpler setup of having a single broker (or cluster of brokers). �Since the services and clients will literally be distributed across the world, however, our product owner did not want all traffic to have to go over the WAN (in some cases volume may be high). �In addition, each geographic location needs to be able to continue to operate in a basic fashion if it becomes disconnected from the WAN (with the understanding that the set of available services may be smaller during the disconnected period).</div>
<div style><br></div><div style>You're right about #3 though-- a typo on my part!</div><div style><br></div><div style>Thanks again for the help-- I think I have a basic understanding of my options now...</div><div style>
<br></div><div style>-Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 21, 2012 at 2:34 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chris,<div class="im"><br>
<br>
On 21/12/12 16:59, Chris wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the reply, Tim. �The nodes may be thousands of miles apart<br>
and each geographic location will have its own cluster as well. �We're<br>
trying to find a solution that doesn't require any additional hardware<br>
and can be configured somewhat easily via a GUI. �A load balancer also<br>
would not understand how to properly route based on queues/exchanges--<br>
the key is only to distribute/load-balance over the nodes that actually<br>
have consumers for the given exchange/queue.<br>
</blockquote>
<br></div>
It is not quite clear what problem you are trying to solve. In your original email you said:<br>
<br>
<quote><div class="im"><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 X on Broker A<br>
2) Submit job with routing key Y from Broker A: Should go ONLY to Consumer of Y on Broker A<br>
3) Submit job with routing key Z from Broker A: Should go to Consumer of Z on Broker A<br></div>
</quote><br>
<br>
Re (3) - there is no consumer of Z on A. I'm guessing you meant B.<br>
<br>
Overall, I am guessing what you are trying to say here is that you have three types of task - X,Y,Z - and workers that know how to process a sub-set of these tasks, and that these workers might be in different locations. And each task should be processed by only one worker.<br>
<br>
So why not simply have a single broker, in one location, with three queues - X, Y, Z? Workers, wherever they are, connect to the broker and start consuming from the queues whose tasks they can handle.<br>
<br>
One step up from this simple set up would be a federation where the X, Y, Z queues reside on different brokers in the federation. The main complication that creates is that workers need to know which of the federated brokers they need to connect to.<br>
<br>
Beware of premature optimisations. I'd stick with the simple setup unless you have determined experimentally that it does not perform adequately for your use case.<br>
<br>
Regards,<br>
<br>
Matthias<br>
</blockquote></div><br></div>