<div dir="ltr">Note, this is why you have clustering and failover (i.e. load balancers) between your client and rabbit servers. Then across sites you can do shoveling/federation for further disconnects. But generally with-in a local area network, a load balancer works wonders for this. See:<div>
<a href="http://rabbitmq.com/ha.html">http://rabbitmq.com/ha.html</a></div><div>for some more details,<br><div>Jason</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 3:50 PM, Thierry Thelliez <span dir="ltr"><<a href="mailto:thierry.thelliez.tech@gmail.com" target="_blank">thierry.thelliez.tech@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Yes, I agree that a local queue might not be the answer (and we could go in a recursive argument;-).</div>
<div><br></div><div>But I guess that the client/producer should have a way to store events in case the message broker goes down. Using a local database might be an option (although that's just another moving part and that could be considered like a local queue system as well).</div>
<div><br></div><div>I am just curious about what people do in production. </div><div><br></div><div>I need to send user generated files to a conversion worker pool. If the message broker goes down for any reason, the clients/producers need to continue dealing with the incoming traffic and locally store the files until the broker goes back up. In other words, it seems like the client needs to keep a record of the ongoing transactions/conversions. Is that correct?</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Thierry</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jul 22, 2013 at 1:14 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thierry,<div><br>
<br>
On 20/07/13 00:12, Thierry Thelliez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Interesting discussion. I am new to RabbitMQ and I am trying to<br>
understand the coding and architecture requirements on the Producer side.<br>
<br>
What happens if the Producer cannot push to a queue? Does that mean<br>
that the Producer system should plan for its own local queue until the<br>
broker is back? What do you do in production when you do not want to<br>
loose these messages?<br>
</blockquote>
<br></div>
That depends on the app and what failure scenarios you are most concerned about.<br>
<br>
Local queues add another moving part that itself can fail.<br>
<br>
<br>
Note that the thread discussed blocked producers. No messages are lost in that situation; message loss would only occur if client or server are terminated/crash or there is a prolonged network disruption.<span><font color="#888888"><br>
<br>
<br>
Matthias.<br>
</font></span></blockquote></div><br></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><br clear="all"><div><br></div>-- <br>Jason McIntosh<br><a href="http://mcintosh.poetshome.com/blog/">http://mcintosh.poetshome.com/blog/</a><br>573-424-7612
</div>