<div dir="ltr">Hi Guillaume,<div><br></div><div style>Wiser heads will no doubt correct me, but:</div><div style><br></div><div style>1. Durable queues != durable messages: for your messages to (possibly) still be there after a crash you must indicate that they are persistent (delivery_mode=2).</div>
<div style><br></div><div style>2. You can cross-link your exchanges/queues using shovels such that messages appear in both servers in a symmetric manner. I have personally found this easier to: understand, configure, implement, and operate than federation, but don't let me discourage you from trying federation as well!</div>
<div style><br></div><div style>3. We do health checks and automated failover using AWS Route 53: a smart DNS service - works fine, so you are good there.</div><div style><br></div><div style>4. Bonus: we actually exchange messages twice between servers (actually clusters), once before they are 'processed' and once after they are 'processed'. We do this because our own processing steps are the least reliable and most time consuming portion of each message pipeline, hence failures tend to occur there. This results in duplicate messages after processing (actually triplicate in our case). We have a 'resolver' layer that de-duplicates and continuously reports on paths and latencies, as well as the successful processing of each message.</div>
<div style><br></div><div style>Michael Laing</div><div style>NYTimes</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 9:19 PM, Guillaume Ouellet <span dir="ltr"><<a href="mailto:gui.ouellet@gmail.com" target="_blank">gui.ouellet@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div>
<br></div><div>The producer client code will implement 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. </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<div><div class="h5"><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, <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></div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>