<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>