[rabbitmq-discuss] Cleaning up unhandled messages

[Jerry Kuch]

> I've implemented the following before.
>
> * Consumer gets a message
> * Consumer throws exception
> * Consumer stores md5sum of message in array of "bad messages"
> * Consumer gets the message again
> * Consumer throws exception
> * Consumer checks bad messages array
> * Bad message exists already, ack it, and publish the message to an
errors exchange.
> * Errors exchange has a queue/consumer that logs to disk, sends alerts, etc.

This is a viable sounding scheme, although I wonder...  Would the
semantics of AMQP's basic.reject, as described here:

http://www.rabbitmq.com/blog/2010/08/03/well-ill-let-you-go-basicreject-in-rabbitmq/

...do what you want?

This method allows your consumer to, rather than basic.ack-ing a
message that has been delivered to it, to sort of "anti-ACK" it,
declaring that it can't be processed.  If you basic.reject a method
with the 'requeue' parameter set to false, the message will be
discarded rather than put back into the queue for future redelivery.

As described in the post I link above, there's some modestly
Mephistophelean details in what the AMQP spec says about the
basic.reject method and how it should work, but what RabbitMQ has
chosen to implement aims to be the most straightforward thing that is
actually useful.  Modulo a special circumstance such as you having
multiple consumers on a queue, with only some of them for some reason
unable to cope with the so called "bad message," it seems it should handle
your needs.

Best regards,
Jerry