Message acks after connection outages

[Milan Gornik]

Hello,

I have a question on message acks and their use during/after connection outages. In my use-case, messages are received into several buffers, and then when these buffers are purged, messages are explicitly acknowledged in the code. Several seconds can pass between message receiving and acknowledge. I noticed that when connection breaks, and I try to ack message immediately afterwards, I will get precondition error reported stating that the delivery tag is unknown:

ModelShutdown event called on RabbitMQConsumer. Reason is: PRECONDITION_FAILED - unknown delivery tag 1077.

This is the part of the docs talking about this, but I'm not sure how to do this:

"...After connection recovery, RabbitMQ will reset delivery tags on all channels. This means that basic.ack, basic.nack, and basic.reject with old delivery tags will cause a channel exception. To avoid this, RabbitMQ .NET client keeps track of and updates delivery tags to make them monotonically growing between recoveries. IModel.BasicAck, IModel.BasicNack, and IModel.BasicReject then translate adjusted delivery tags into those used by RabbitMQ. Acknowledgements with stale delivery tags will not be sent. Applications that use manual acknowledgements and automatic recovery must be capable of handling redeliveries..."

When message is received, its delivery tag is stored in memory (unsigned long). What should I do with it when connection breaks, and that message needs to get acknowledged? How do I translate it to delivery tags used by RabbitMQ? Docs state that recovery must be capable of handling redeliveries. Does it mean that if consumer received a message and connection breaks, it shouldn't even try to acknowledge it (even if it is processed), but rather expect this same message to be redelivered (to the same or some other consumer)?

Rabbit server being used: RabbitMQ 3.6.2, Erlang 18.3, Rabbit client being used: C# client 3.6.2

Many thanks,

Milan Gornik

[Karl Nilsson]

Hi,

Unacked messages will be redelivered after a connection recovers after an outage. The error you are seeing is due to a bug which should have been fixed in the 3.6.3 client (see: https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/203). The stale delivery tag should have just been silently ignored so I that it is safe for you to try to ack the message that was received before the connection outage. Your application logic will need to cope with the redelivery of the same message. 

Cheers

Karl

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Karl Nilsson

Staff Software Engineer, Pivotal/RabbitMQ

[Milan Gornik]

Hi Karl,

Many thanks for the info. I will upgrade my client to 3.6.3 and retry
the testing scenarios.

When you say app needs to cope with it do you mean it needs to cope
with the message being delivered twice (once before the connection
outage and once after connection restarts)?

Regards,
Milan

> You received this message because you are subscribed to a topic in the
> Google Groups "rabbitmq-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/rabbitmq-users/SmbjLjsp-eU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Karl Nilsson]

Yes - possibly even more than twice if there are additional connection failures.

To post to this group, send an email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Milan Gornik]

Great. I fully understand the workflow now and the steps I need to
take to fix the issue on my side.

Many thanks, Karl!