How do I set a number of retry attempts in RabbitMQ?

Question

I am using RabbitMQ and I have a queue that holds email messages. My consumer service de-queues messages and attempts to send them. If, for any reason, my consumer cannot send the message, I would like to re-queue the message to send again.

I realize I can do a basicNack and set the requeue flag to be true, however, I don't want to requeue the message indefinitely (say, if our email system goes down, I don't want to continuously requeue unsent messages). I would like to define a finite number of times that I can requeue the message to be sent again.

I can't set a field on the email message object, however, when I dequeue it and send a nack. The updated field is not present on the message in the queue.

Is there any other way in which I can approach this?

Answer 1

Update from 2023 based on quorum queue's way of poison message handling:

Quorum queues keep track of the number of unsuccessful delivery attempts and expose it in the "x-delivery-count" header that is included with any redelivered message.

They've also added a support of policies to limit re-deliveries:

It is possible to set a delivery limit for a queue using a policy argument, delivery-limit.

So given this new additions (and deprecation of classic queues) the original answer below might be no longer relevant for latest RabbitMQ versions.

Original answer (before queue and stream queues were added):

There are no such feature like retry attempts in RabbitMQ (as well as in AMQP protocol).

Possible solution to implement retry attempts limit behavior:

1. Redeliver message if it was not previously redelivered (check redelivered parameter on basic.deliver method - your library should have some interface for this) and drop it and then catch in dead letter exchange, then process somehow.

2. Each time message cannot be processed publish it again but set or increment/decrement header field, say x-redelivered-count (you can chose any name you like, though). To get control over redeliveries in this case you have to check the field you set whether it reaches some limit (top or bottom - 0 is my choise, a-la ttl in ip header from tcp/ip).

3. Store message unique key (say uuid, but you have to set it manually when you publish message) in Redis, memcache or other storage, even in mysql alongside with redeliveries count and then on each redelivery increment/decrement this value until it reach the limit.

4. (for real geeks) write plugin that will implement such behavior like you want.

The pro of #3 is that redelivered message stay in queue head. This is important if you have long queue or if message order is important for you (note, that redeliveries will break strict messages order, see official docs for details or this question on SO).

P.S.:

There is similar answer in this topic, but in php. Look through it, maybe it helps you a bit (start reading it from words "There are multiple techniques to deal with cycle redeliver problem".

Answer 2

Although this is an old question I think you can now easily do this with the combination of dead letter exchanges and the x-death header array added once a message is dead lettered:

The dead-lettering process adds an array to the header of each dead-lettered message named x-death. This array contains an entry for each dead lettering event, identified by a pair of {queue, reason}. Each such entry is a table that consists of several fields:

queue: the name of the queue the message was in before it was dead-lettered

reason: reason for dead lettering, see below

time: the date and time the message was dead lettered as a 64-bit AMQP 0-9-1 timestamp

exchange - the exchange the message was published to (note that this will be a dead letter exchange if the message is dead lettered multiple times)

routing-keys: the routing keys (including CC keys but excluding BCC ones) the message was published with

count: how many times this message was dead-lettered in this queue for this reason

original-expiration (if the message was dead-letterered due to per-message TTL): the original expiration property of the message. The expiration property is removed from the message on dead-lettering in order to prevent it from expiring again in any queues it is routed to.

Read this great article for more info

Check this diagram:

Answer 3

You should use Quorum queue type. That queue type has a Delivery limit argument to specify the number of retries to deliver a message before deleting it.

Specify next arguments when create your queue:

x-queue-type: quorum
x-delivery-limit: 3 // it means rabbitmq will make 3 attempts to deliver a message before deleting it 

Answer 4

From my perspective the better idea here is to implement a combination of dead-letter exchange and retry logic inside of the consumer. If the consumer fails to handle the message then you put a message into a DeadLetterQueue

Bellow you can find a prototype of dead-letter-exchange implemented with node-amqp and Rabbitmq https://github.com/kharandziuk/dead-letter-exchange-prototype.

Answer 5

After several attempts with various solutions (including from other answers here, inspired from the post from Erez Rabih); I came up with a mecanism using both a DLX and a Delayed Exchange. And wrote this post to explain.

---

Needs

Basically for a perfect full retry mecanism, you want :

1. Requeue at the tail of the original queue (not to lock it)
2. Being able to limit the number of retries (not to retry indefinitely)
3. Being able to wait between retries (to improve retry success chance)
4. (BONUS: being able to control delays between retries)

---

A semantic, simple yet powerful solution

This is what I came up with on various projects :

It's using

• a simple, semantic Dead Letter Exchange setup on work queues (just nack the messages without requeuing)
• an 'error-queue' with a simple consumer, calculating next retry delay
• a Delayed Exchange 'wait-exchange', where 'error-queue' publishes with custom x-delay
• a 'requeue-queue' bound to 'wait-exchange', with a consumer simply responsible of requeuing to original queue

You can read this post where I explain this further.