<div dir="ltr">Hi Emile,<div><br></div><div>Firstly, thanks for the reply and for raising the priority of this feature. I am sure it won't only be us that will appreciate this. :)</div><div><br></div><div>I totally understand that doing a 'proper' implementation of toxic message handling is a complex task and would not be suitable for a plugin. What I am after is something that would satisfy our system specific requirements in the meantime. The idea I had was to simply plug something into the channel deliver/redeliver function to add / increment a custom header value that we could later inspect in the consumers. This value doesn't even have to be very accurate (e.g. taking replication / failover into account). All we want to achieve is to have some indication of a message being one that has been redelivered multiple times and then take some action based on that.�</div>
<div><br></div><div>Is it technically possible to do this using the plugin architecture? If so, I'd appreciate any pointers of as to how.�</div><div><br></div><div>Using multiple queues is an additional complexity that I'd like to try to avoid as long as possible.</div>
<div><br></div><div>Karl</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 November 2013 12:18, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<div class="im"><br>
<br>
On 13/11/13 11:55, Karl Nilsson wrote:<br>
<br>
> I know there is a planned feature for this (basic / deliver / 01) but I<br>
> checked with Alvaro who has confirmed it isn't a priority at this time<br>
> so we could do with some kind of half-way house in the meantime.<br>
<br>
<br>
</div>The priority of this feature has just raised because it is determined in<br>
part by demand.<br>
<br>
The complete implementation of toxic message handling is complicated by<br>
the need for on-disk representations to change in order to accommodate<br>
the counter information. Maintaining the counter in RAM is not an option<br>
since the redelivery information could be unbounded.<br>
<br>
This feature would need to modify and interact with multiple broker<br>
subsystems, so not the ideal for a plugin.<br>
<br>
The best alternative at present is to use the redelivery flag as an<br>
indicator that a message may be suspect. It is possible to extend the<br>
utility of the redelivery flag slightly by republishing redelivered<br>
messages to a separate queue for high-risk messages. If messages from<br>
the high-disk queue again have the redelivery flag set then the message<br>
is probably toxic and should be handled as an exception.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></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>