CODEWITHSUNDEEP
rabbitmqrabbitmq-exchange
lf215
lf215

Reputation: 1009

rabbitmq: can consumer persist message change before nack?

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.

Upvotes: 4

Views: 1619

Answers (2)

Bierbarbar
Bierbarbar

Reputation: 1479

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

Upvotes: 0

cantSleepNow
cantSleepNow

Reputation: 10192

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

Upvotes: 1

Related Questions