dealing with poison-pill messages

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

dealing with poison-pill messages

john doe-73
Hello there,

I am aware the topic is marked as "planned" in rabbitmq's roadmap, but
I'd like to have your opinion of a quick-and-dirty way to handle this.

So the issue here is that we want to deal with:
- the case where a consumer crashes or is stopped in the middle of
processing a message (we want the message to be sent to another
- the case where a message is somehow corrupted and cause any consumer
to crash (we don't want all our consumers to crash)

Here is a solution proposal, using a special flag (I used
delivery.getProperties().getType()) on the message. When a consumer
get a message:
a) if isRedeliver=false and flag=false, consumer processes the message
the regular way, then it acks the message
b) if isRedeliver=true and flag=false, consumer duplicates message,
then enable the flag on the duplicated message, then send this new
message to its own queue and acks the original message without
actually processing it
c) if isRedeliver=false and flag=true, consumer knows that this
message may cause it to crash, but it will try to process it
d) if is Redeliver=true and flag=true, consumer knows that this
message already caused two consumers to crash, so it will acknowledge
the message without even processing it.

In case of a poison-pill scenario, steps a b c d will happen in that
very order and at most two consumers will die.

There is a corner case though: if during steps a) and c) consumer is
killed by something else, a message may be considered as harmful
whereas it is not. But that should not happen very often.

What do you think?


rabbitmq-discuss mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: dealing with poison-pill messages

Emile Joubert

Hi John,

On 19/03/12 11:07, john doe wrote:
> What do you think?

You describe a reasonable emulation of toxic message handling. You
should be aware that republishing messages will destroy order, so this
solution is only applicable in scenarios where message ordering is

As an enhancement you could also consider marking the message with a
number instead of a flag to count how many times processing as been
attempted. You could also consider decorating the message with the
consumer identity to distinguish between processing attempts by
different consumers.


rabbitmq-discuss mailing list
[hidden email]