1

We have a SpringBoot service implementation in which we are using delayed messaging with the below setup:

  1. Initial queue (Queue 1) that gets the message has a TTL set, the queue also has a dead letter exchange mentioned with a specific dead letter routing key.
  2. Another queue (Queue 2) is bound to the DLX of the previous queue with the routing key which is set as the dead letter routing key
  3. A consumer listens to the messages on Queue 2.

The delayed messaging seems to work as expected but I am seeing an issue with messages getting redelivered in certain scenarios.

If I have a debug point in my consumer and keep the message just after reading it for some time then once the current message has been processed consumer gets another message which has the below properties:

  • Redelivered property as true.
  • Property deliveryAttempt as 1
  • Only the first message has an x-death header and redelivered messages do not seem to have it.

The attempt to deliver the message is done 3 times as many times as I pause the consumer using the debug point each time after reading each redelivered message.

My understanding was that the acknowledgment mode by default is AUTO so once the consumer has read the message then it would not be redelivered?

I have tried using maxAttempts=1 property but does not seem to help.

I am using the spring cloud stream to create the consumers and the queues.

RaRa
  • 140
  • 7
  • Setting `maxAttempts` to 1 will disable retries in the binder; so something is wrong with your config. – Gary Russell Oct 04 '22 at 15:09
  • @GaryRussell I came across a mention of the heartbeat property, could this be causing the messages to be redelivered? I observe that the redelivery happens if I pause the consumer through the debugger for close to 60 seconds. Also, the number of redeliveries could be more than 3, basically, it depends on the time I pause on each message in the consumer, and also the deliveryAttempt is always 1. – RaRa Oct 04 '22 at 19:56

1 Answers1

0

I used to run into this issue when the message processing in the consumer failed (exception thrown). In this case, if you have DLQ configured, make sure to add the following configuration as well so the failed message will be routed to the DLQ not the original listening queue. " rabbit: autoBindDlq: true "

Otherwise if you don't set up the DLQ, configure "autoBindDlq" to "false".

Wally Liu
  • 85
  • 7