Here's what we have here:
DLE
, which is intended to be a Dead-Letter ExchangeE
, which is the "main" ExchangeEQ1
, ..., EQn
) bound to E
(and initialized with x-dead-letter-exchange = DLE
), each with own Routing Key. These queues are the ones being consumed from.EQn
, there's a DLEQn
(initialized with x-dead-letter-exchange = E
and x-message-ttl = 5000
), bound to DLE
with the same routing key as EQn
. These queues are not being consumed fromWhat I want is the following: if a consumer cannot process a message from EQn
, it Nacks the message with requeue: false
and it gets to the DLEQn
- that is, to an appropriate queue on the Dead-Letter Exchange. Now, I want this message to sit on the DLEQn
for some time and then get routed back to the original queue EQn
to be processed again.
Try as I might, I could not get the "redelivery to the original queue" working. I see that messages sit in the DLEQn
with all the right headers and Routing Key intact, but after TTL expires they just vanish into thin air.
What am I doing wrong here?
Messages from a queue can be "dead-lettered"; that is, republished to an exchange when any of the following events occur: The message is negatively acknowledged by a consumer using basic. reject or basic.
Dead-letter exchanges in Message Queue for RabbitMQ are used to process the messages that are negatively acknowledged by consumers or for which all retries fail.
The purpose of the dead-letter queue is to hold messages that cannot be delivered to any receiver, or messages that could not be processed. So, any message that resides in the dead-letter queue is called a dead-lettered message.
You need to configure a "dead letter queue" to handle messages that have been rejected or undelivered. Using the RabbitMQ Client library, you can bind a consumer to that configured queue and retrieve the messages from it. From there you decide in code what you want to do to reprocess/reject them completely.
Yes, you can do this. We are currently doing this in production and it works great. The code is too long to include here but I will show you the diagram I created that represents the process. The basic idea is that the First DLX has a TTL, once that TTL expires the message goes into a 2nd queue to be re-sent back into the original.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With