<div dir="ltr">A trick is to make your messages idempotent. Then you can reissue the same request again after a timeout, should you have had no response yet. It is a protocol design trick that often helps because it circumvents the problem of keeping state entirely. Also look at "best effort" delivery.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 26, 2013 at 11:18 PM, Alvaro Videla <span dir="ltr"><<a href="mailto:videlalvaro@gmail.com" target="_blank">videlalvaro@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also I think it might be worth mentioning the "Publisher Confirms"<br>
feature of RabbitMQ: <a href="http://www.rabbitmq.com/confirms.html" target="_blank">http://www.rabbitmq.com/confirms.html</a> in case you<br>
need to be sure a message was taking care by the server.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Alvaro<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 26, 2013 at 11:14 PM, Michael Klishin<br>
<<a href="mailto:mklishin@gopivotal.com">mklishin@gopivotal.com</a>> wrote:<br>
><br>
> On 26 Nov 2013, at 23:35, Alfonso Alvz <<a href="mailto:alfonso.alvz@gmail.com">alfonso.alvz@gmail.com</a>> wrote:<br>
><br>
>> I was wondering if there's is a way to make the messages persistent in case the server fails?. If the client sends a message with no server running, it stays there awaiting for the response and it doesn't get anything once the server goes up again..<br>
><br>
> Accumulate messages in the client and re-publish them when a new connection is up. Note that to really<br>
> make this work you’ll need to have a WAL (write-ahead log) of messages on disk to significantly reduce<br>
> message loss probability when your publisher crashes, runs out of memory, etc.<br>
><br>
>><br>
>> Having a configuration like this:<br>
>> If the server disappears, is there a way to resume the process whenever the server is up again?<br>
><br>
> Some clients support automatic recovery but currently don’t provide WAL’s. 3rd party projects built on top<br>
> of clients (e.g. Hutch, Celery or EasyNetQ) may choose to provide WAL and more advanced features<br>
> but it is currently out of scope for the protocol clients.<br>
><br>
> Message durability controls whether the message will be stored on disk by RabbitMQ. It has no effect<br>
> on what happens when you publish messages on a closed connection.<br>
><br>
><br>
> MK<br>
><br>
> Software Engineer, Pivotal/RabbitMQ<br>
><br>
><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>
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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>J.
</div>