4

Before a consumer nacks a message, is there any way the consumer can modify the message's state so that when the consumer consumes it upon redelivery, it sees that changed state. I'd rather not reject + reenqueue new message, but please let me know if that's the only way to accomplish this.

My goal is to determine how many times specific messages are being redelivered. I see two ways of doing this:

(1) On the message itself as described above. The message would be a container of basic stats and the application payload message.

(2) In some external storage. We would uniquely identify the message by the message id that we set.

I know 2 is possible, but my question is if 1 is possible.

lf215
  • 1,185
  • 7
  • 41
  • 83
  • When you say modifying the state of the message does it mean that its just another flag in the message itself? Something like modifying the message content before doing a Nack ? – Mitra Ghorpade Feb 08 '17 at 17:15
  • It would have to be an integer. By flag I assume you mean a Boolean – lf215 Feb 08 '17 at 17:16
  • Nah just wanted to make sure its the message thats getting updated before we do Nack.. Cause you do have control over the message before doing a Nack but not sure once you update the message will it be the same message or a new one.. Cause if the id changes then it will be difficult to trace the message. – Mitra Ghorpade Feb 08 '17 at 17:20

2 Answers2

1

There is no way to do (1) like you want. You would need to change the message, thus the message would become another message. If you want to do something like that (and it's possible that you meant this with I'd rather not reject + reenqueue new message) - you should ACK the message, increment one field in it and publish it again (again, maybe this is what you meant when you said reenqueue it). So your message payload would have some ID, counter, and again (obviously different) payload that is the content.

Definitvly much better way is (2) for multiple reasons:

  • it does not interfere with business logic, that is this diagnostic part is isolated
  • you are leaving re-queueing to rabbitmq (as you are supposed to do), meaning that you are not worrying about losing messages and handling some message meta info which has no use for you business logic
  • it's actually supposed to be used - the ACKing and NACKing, that's why it's in the AMQP specification
  • since you do need the number of how many times specific messages have been redelivered, you have it somewhere externally, meaning that it's independent of (rabbitmq's) message persistence, lifetime, potentially queue durability mirroring etc
cantSleepNow
  • 9,691
  • 5
  • 31
  • 42
0

Even if this question was marked as solved some time ago, I want to mention that there is a way at least for the redelivery. It might be integrated after the original answer. There is a different type of queues in RabbitMQ called Quorum queues.

Quorum queues offer the option to set redelivery limit:

Quorum queues support poison message handling via a redelivery limit. This feature is currently unique to Quorum queues.

In order to archive this, RabbitMQ is counting the numbers of deliveries in the header. The header attribute is called: x-delivery-count

Bierbarbar
  • 1,399
  • 15
  • 35