<div dir="ltr">Hi Thomas,<div><br></div><div>It is a great shame that a mature message broker such as RabbitMQ is so lacking in sensible poison message handling (or any strategies regarding redelivery). I raised the issue here a few months ago and was advised the priority of planned feature [basic / deliver / 01] had been raised but wasn't given any indication of when it might be delivered.�</div>
<div><br></div><div><a href="http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/27733">http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/27733</a><br></div><div><br></div><div>After that I wrote a blog entry summarising my investigations which includes some of the suggested workarounds (such as using multiple queues), none of which I consider adequate.�</div>
<div><br></div><div><a href="http://kjnilsson.github.io/blog/2014/01/30/spread-the-poison/">http://kjnilsson.github.io/blog/2014/01/30/spread-the-poison/</a><br></div><div><br></div><div>There is an argument for not designing systems where losing a message is a big deal but I think that is a topic of a different discussion. :)</div>
<div><br></div><div>Cheers</div><div>Karl</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 March 2014 19:31, Thomas Riccardi <span dir="ltr"><<a href="mailto:riccardi@systran.fr" target="_blank">riccardi@systran.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Consumer crash, redelivery and prefetch<br>
<br>
Hi,<br>
<br>
I'm having issues with consumer crash, redelivery and prefetch:<br>
<br>
The messages ack strategy I've chosen is to ack the message only after<br>
the consumer has finished working on the message. I need this because I<br>
cannot aford any lost message, even in case of consumer crash during the<br>
work on the message.<br>
<br>
For performance reason my consumer have a non 0 prefetch, so when my<br>
consumer is handling a message (doing some work related to the message),<br>
other messages are pushed to the client so that it has them already<br>
available when it's done working on the previous message.<br>
<br>
With this, when a message makes the consumer crash, the handled message<br>
*and* the prefetched ones are re-queued, with the flag "redelivered" ==<br>
1.<br>
<br>
I currently have no other choice than rejecting all messages that have<br>
the "redelivered" flag set to true, because I have no way to distinguish<br>
the message that cause the crash from the prefetched ones that did<br>
nothing wrong.<br>
Indeed if I retry to work on a redelivered message, the consumer will<br>
crash again on the poison message, in an infinite loop. However I would<br>
like to not reject the previously prefetched messages since they are<br>
probably OK.<br>
This reasoning also applies to transient crashes that are not<br>
systematically reproduced by the message.<br>
<br>
<br>
Ideally the solution would be to be able to distinguish the first non<br>
ack'd message from the other ones when the consumer crashes, or<br>
alternatively having two types of ack : one "I'm starting to work on<br>
this message", and a second one "I've finished working on this message".<br>
<br>
Otherwise a redelivery count would do the trick (even if it means<br>
working multiple times on a message that did make the consumer crash,<br>
which is not efficient if we know crashes happen mostly systematically).<br>
<br>
The redelivery count is a "planned" feature according to<br>
<a href="http://www.rabbitmq.com/specification.html" target="_blank">http://www.rabbitmq.com/specification.html</a>, but when will it be really<br>
implemented?<br>
Having a parameter per queue like the TTL to tell a maximum redelivery<br>
count before dead lettering the message would be much helpful in my case<br>
(a RPC above rabbitmq, which is probably not a highly specific and rare<br>
use-case).<br>
<br>
<br>
Thanks,<br>
Thomas<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><b>Karl Nilsson</b><div>twitter: @kjnilsson</div><div>blog:�<a href="http://coderkarl.wordpress.com/" target="_blank">coderkarl.wordpress.com</a></div>
</div>