Ok, I think I have found a way to solve this issue.<br><br>My queues will be durable, so if the server crashes, the queues will be reloaded on boot up. The servers RAID configuration will make sure we don't loose any items from our queue.&nbsp;<div><br></div><div>The producer client code will implement &nbsp;a logic where if the primary hostname can't be reached, we will send the items to the secondary hostname. The consumers will listen to both hostname.&nbsp;</div><div><br></div><div>2 questions:</div><div><br></div><div>1. Is this approach flawed ?</div><div>2. I am using c# client, and I can't find in the doc any scheme for alternate nodes in case the primare fails? Is there any implementation similar to this, or I'll have to do my own ?</div><div><br></div><div>Thanks<br><br>On Wednesday, 10 July 2013 15:27:43 UTC-4, Guillaume Ouellet  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi all,&nbsp;<div><br></div><div>I am trying to use RabbitMq so that I have one instance of RabbitMQ on each of my 2 servers that are separated by a WAN. One server would be active, the other "inactive", but the inactive would actually have the queue from the active replicated real-time. This way, if the active server goes down, the inactive server kicks in, and continues where the active left off.<br><br>It seemed like the clustering option does exactly this, but as I said previously, I am over a WAN, and a WAN configuration is not recommended.</div><div><br></div><div>My question is how would I implement the previous logic via shovels or federations ? I can't seem to get my head around this looking at the documentation.</div><div><br></div><div>Thank you</div><div><br></div><div><br></div></blockquote></div>