[rabbitmq-discuss] Push to back of Queue on NAck

[Stefan Kaes]

Hi,

I tried this, with a slight modification:

Instead of having a dedicated second exchange, I use the default exchange and set the routing key to the name of the queue I want it routed to.

Queue A, no TTL, x-dead-letter-exchange='', x-dead-letter-routing-key='B'
Queue B, ttl of (x) seconds, x-dead-letter-exchange='', x-dead-letter-routing-key='A'

Works like a charm.

However, there's a problem, which I think will prevent us from using this approach:

The size of the x-death header attached to the message grows linearly with the number of dead lettering events.

This is bad for performance, and in the worst case could crash rabbitmq with an out of memory error, if for some reason a message gets rejected a high number of times (or indefinitely).

It would be great if the x-death header could be limited to have only a bounded number entries, say the last 10 events.

Plus maybe the total number of redirects.

Cheers,

Stefan Kaes



On Fri, Jul 26, 2013 at 11:18 PM, Matthias Radestock <matthias at rabbitmq.com<mailto:matthias at rabbitmq.com>> wrote:
Queue A, no TTL, DLX=Exchange B (with Queue B bound to it).
Queue B, ttl of (x) seconds, DLX= Exchange A (with Queue A bound to it).

When we NAck the mesage from Queue A, we set requeue=false.

Yep, that makes perfect sense and should work well.


I'll give the using-deadletter-exchange with NAck approach a go.



On Sat, Jul 27, 2013 at 1:49 AM, Tom Anderson <tom.anderson at timgroup.com<mailto:tom.anderson at timgroup.com>> wrote:

Implemented exactly as described there, it yields an infinite loop for unprocessable messages. You might therefore also want to keep a count of the number of processing attempts in a header on the message, and more thoroughly reject messages which reach some maximum number of attempts. I think you could do the final rejection by setting a routing key on the message when you reject it for the last time, and having exchange B be a direct exchange which routes to either queue B or some final deadletter queue.


Yep, we've got other ways to deal with permanent failures/poison messages.
This is purely to deal with transient problems where we might need to try several times.


Thanks for the feedback and discussion everyone.
Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130728/00d695ef/attachment.htm>