[rabbitmq-discuss] Delivery / Redelivery counter plugin

[Karl Nilsson]

Hi Emile,

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. :)

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.

Is it technically possible to do this using the plugin architecture? If so,
I'd appreciate any pointers of as to how.

Using multiple queues is an additional complexity that I'd like to try to
avoid as long as possible.

Karl


On 13 November 2013 12:18, Emile Joubert <emile at rabbitmq.com> wrote:

>
> Hi,
>
>
> On 13/11/13 11:55, Karl Nilsson wrote:
>
> > I know there is a planned feature for this (basic / deliver / 01) but I
> > checked with Alvaro who has confirmed it isn't a priority at this time
> > so we could do with some kind of half-way house in the meantime.
>
>
> The priority of this feature has just raised because it is determined in
> part by demand.
>
> The complete implementation of toxic message handling is complicated by
> the need for on-disk representations to change in order to accommodate
> the counter information. Maintaining the counter in RAM is not an option
> since the redelivery information could be unbounded.
>
> This feature would need to modify and interact with multiple broker
> subsystems, so not the ideal for a plugin.
>
> The best alternative at present is to use the redelivery flag as an
> indicator that a message may be suspect. It is possible to extend the
> utility of the redelivery flag slightly by republishing redelivered
> messages to a separate queue for high-risk messages. If messages from
> the high-disk queue again have the redelivery flag set then the message
> is probably toxic and should be handled as an exception.
>
>
>
> -Emile
>
>
>
>
>
>
>
>
>
>
>


-- 
*Karl Nilsson*
twitter: @kjnilsson
blog: coderkarl.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131113/f6ca9f49/attachment.htm>