Thanks for the reply.<div><br></div><div>The odd thing about the federation plugin is that the downstream broker, which is the 'master' conceptually in my case, has to declare its exchange type as 'federation', which means the actual type is based on the upstream 'slave' exchange. That feels strange to me, because I don't want the master to really care about the upstream exchange - it's sort of optional. If the upstream broker is alive that's great, and I want it to forward messages along to the master. If it's not, or isn't present when the master starts, I don't want that to be a problem.</div><div><br></div><div>Maybe I'm not understanding federation correctly? It just struck me as odd that the master has to go declaring all of the upstream sources it expects, and the other way (with shovel) seemed more natural.</div><div><br></div><div>I understand that the sources and destination fields accept a list for the purpose of failover. I could configure a single shovel that consumes from either broker in the 'slave' cluster and publishes to either broker on the master cluster, but I'm worried about the shovel's host broker failing and taking the shovel down.</div><div><br>On Friday, June 29, 2012 12:31:41 AM UTC-7, Brendan Hay wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Eric,<div><br></div><div>FYI: The 'sources' and 'destinations' configuration fields both accept a list. The shovel plugin doesn't actually pull/push to/from all of these simultaneously, it uses them as a form of simple failover - if a connection fails, it uses the next one in the list.</div>
<div><br></div><div>It sounds like for your scenario (when clustering in general), it would be easier to use the federation plugin (<a href="http://www.rabbitmq.com/federation.html" target="_blank">http://www.rabbitmq.com/<wbr>federation.html</a>). When you declare a federated exchange on the downstream/master cluster, the plugin auto-magically declares queues (mirrored if configured) on the upstream/AWS cluster .. you would then bind a mirrored queue to the federated exchange on the downstream/master cluster to cause messages to be routed across the link to that queue.</div>
<div><br></div><div>The plugin will then stay connected even if one of your nodes on either cluster go down .. if the whole downstream/master cluster goes away/down, then messages will pile up in the upstream/AWS queues, and be transfered once the link is re-established.</div>
<div><br></div><div>Does that solve your use-case?</div><div><br></div><div>Regards,</div><div>Brendan<br></div>
</blockquote></div>