<div dir="ltr">It's a good topic. <div><br></div><div>In our std framework, based on python pika, a service may fail in processing a message due to an exception being raised - something unanticipated - the service will have chosen a default action to take in that case when it was initialized, typically 'reject'. Typically it will log a warning as well.</div>
<div><br></div><div>We gather rejected messages in a 'reject' exchange and process them enough (via their headers) to route them back to their originators as well as to our own 'triage' queue.</div><div><br>
</div><div>Our messages all carry their processing history in their headers: region, zone, instance, pid, service, timestamp, etc. - again part of the framework.</div><div><br></div><div>We also gather and coordinate the logs of all services on all instances.</div>
<div><br></div><div>Additionally we replicate messages and process them in parallel through our Core clusters in multiple regions.</div><div><br></div><div>A truly poison message will fail spectacularly everywhere. We have not actually encountered one yet in production. We do get them in staging, and bells go off everywhere.</div>
<div><br></div><div>A failure of infrastructure will be localized to a region, zone, instance, or supporting service like Cassandra or the AWS control plane. Anticipated failures are retried. Unanticipated failures result in rejection of that message replica but other replicas should succeed. We do get these in production and can immediately tell where failures occurred and take appropriate action, e.g. shifting load away from failure if it has not yet taken place automatically.</div>
<div><br></div><div>Of course it would be nice to get more info upon rejection. We compensate by creating context around rejection and coordinating the context in near real time across the <span class="">nyt</span>⨍aбrik.</div>
<div><br></div><div>ml<br></div>







</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 6:06 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 14/03/2014 9:42AM, Karl Nilsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is a great shame that a mature message broker such as RabbitMQ is so<br>
lacking in sensible poison message handling (or any strategies regarding<br>
redelivery).<br>
</blockquote>
<br></div>
Agreed.<br>
<br>
But there are a great many things we want to do, and only limited time to do them in.<br>
<br>
I suspect it will happen one day. Sorry I can't be more specific than that, but we tend not to plan out a long way in advance.<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>