<div dir="ltr">Simon,<div><br></div><div>Thank you so much for your detailed response - it was very helpful to me and answered all of my questions.</div><div><br></div><div style>Regards,</div><div style><br></div><div style>
Richard</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 27, 2013 at 8:19 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 26/02/13 23:41, Richard Raseley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am contemplating the use of topic exchanges along with the federation<br>
plugin to route messages between geographically separated brokers.<br>
<br>
1) Will someone confirm my understanding of the configuration is valid?<br>
<br>
In this situation there would be topic exchange named "B1.TE" "B2.TE"<br>
that would be configured within brokers "B1" and "B2" respectively.<br>
B1.TE would have B2.TE configured as an upstream exchange and B2.TE<br>
would have B1.TE configured as an upstream exchange.<br>
<br>
Broker B1 would have queues "B1.Q1" and "B1.Q2" configured and bound to<br>
exchange B1.TE with routing keys "B1.Q1" and "*.Q2" respectively.<br>
<br>
Broker B2 would have queues "B2.Q1" and "B2.Q2" configured and bound to<br>
exchange B2.TE with routing keys "B2.Q1" and "*.Q2" respectively.<br>
</blockquote>
<br></div>
It is valid, certainly. Note that the exchanges and queues in B1 and B2 do not need to have distinct names (but maybe you were just doing that to be clearer?)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Assuming the answer to question #1 above is "yes, it is valid", would<br>
someone confirm my understanding of how the following messages would be<br>
routed?<br>
<br>
A message sent to exchange B1.TE with routing key "B2.Q1" would be<br>
received, forwarded to exchange B2.TE, placed in queue B2.Q1,<br>
</blockquote>
<br></div>
Yes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and then acknowledgement would be sent back to the client.<br>
</blockquote>
<br></div>
No.<br>
<br>
Assuming the client is publishing in confirm mode, the confirm will be sent back as soon as B1 has taken responsibility for the message. Confirms mean "the broker you published to took responsibility for the message". Otherwise as your federation grows larger and less-reliable network links come into play, you could be waiting a long time for those confirms!<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A message sent to exchange B1.TE with routing key "B1.Q2" would be<br>
received, a copy placed in queue B1.Q2, a copy forwarded to exchange<br>
B2.TE, placed in queue B2.Q2, and then acknowledgement would be sent<br>
back to the client.<br>
<br>
A message sent to exchange B2.TE with routing key "B2.Q2" would be<br>
received, a copy placed in queue B2.Q2, a copy forwarded to exchange<br>
B1.TE, placed in queue B1.Q2, and then acknowledgement would be sent<br>
back to the client.<br>
</blockquote>
<br></div>
Again, yes to the routing, no to when confirmation happens.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) My understanding is that an exchange has knowledge of the routing<br>
topology of any upstream queues and therefore won't send a message<br>
upstream that wouldn't end up in a queue. Firstly, is that understanding<br>
correct?<br>
</blockquote>
<br></div>
I think you mean "downstream" in both cases, but yes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Secondly (if yes to the previous question), what type of<br>
overhead are we talking about when using this configuration with a topic<br>
exchange?<br>
</blockquote>
<br></div>
Effectively the bindings propagate upstream, so each federated exchange will end up with all the bindings for all of its downstreams.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My worry is that the processing power required to deliver each message<br>
will increase exponentially as I add additional brokers in a "mesh"<br>
style federated topology as it seems that the routing table on each<br>
upstream exchange has to be examined for each message delivery.<br>
</blockquote>
<br></div>
Well, it won't be exponential. But the routing table will get larger. Topic routing is approximately O(log n) in the number of bindings.<br>
<br>
The federation mechanism doesn't try to trade routing complexity for unnecessarily-routed messages by amalgamating topic keys since<br>
<br>
�(a) it would have to know about topics for that, it's supposed to be a<br>
� � �generic mechanism<br>
<br>
�(b) it can't know what the distribution of messages across your<br>
� � �routing key space is<br>
<br>
However, *you* know that distribution. So you could federate topic exchanges and then use e2e bindings from them to local topic exchanges, with relatively "large" routing keys that will cover a decent sized range. Then apps bind queues to the local topics. That does require a bit more up-front setup though - but it kind of has to since it requires knowledge of how your routing keys are distributed.<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>