<div dir="ltr"><div><div><div><div><div><div><div><div>Hello,<br></div>I am trying to decide between using Shovel or Federation. Our use case is as follows:<br></div>We have two datacenters: east coast and west coast in the US. We have two clustered rabbitmq nodes in each site. We have messages which are published at each site which need to be reliably consumed at both sites. For example, a message published to exchange A at Site A will need to be consumed at both site A and site B. The messages, exchanges, and queues involved need to be durable, mirrored, etc. in order to ensure reliable delivery of each and every message. <br>
<br></div>Initially, I had leaned toward the shovel plugin for a couple of reasons.<br></div>1) The documentation for shovel seems for straightforward. Using Shovel, I know what happens to the messages in transit because they follow the same message flow as "normal" messages. The plan is to have a fanout exchange at each site which publishes to both a queue for local consumption and a queue that is then shoveled across the WAN to an exchange than points to just the queue for local consumption and vice versa. <br>
</div>Using Federation, I am not fully aware of what would happen. Say I have a fanout exchange configured at Site A. A queue at Site A connects to this queue for local consumption of the messages. Site B then attaches to the exchange via federation. My understanding is that there is then an upstream queue created. If Site B then goes offline, what happens to the messages published to the fanout exchange in Site A. Will the messages sit in the upstream queue until both the queue and the remote are available to fanout messages to? <br>
<br>2) Shovel has "More Control" according to the documentation.<br><br></div>My questions are: Am I missing the boat? Would Federation be much more simple to setup? Would Federation even work in this scenario?<br>
<br></div>In addition: I would like to configure this whole thing via Puppet. I know how to do it in the rabbitmq config for shovel but wouldn't this require a restart when configuration changes are made? Also, would the federation configuration methods via the API lend itself to more simple Puppetization through simple API calls for Federation setup?<br>
<br></div>Thanks,<br>Danny<br></div>