Improve documentation of how to recover from Acknowledgement timeout

[matsev]

Documentation issue

Improve documentation of how to recover from Acknowledgement timeout

Motivation

It is currently unclear for me how an application can recover from an Acknowledgement timeout.

We are using the Reactor RabbitMQ client library configured with consumeManualAck. Occasionally, we observe the following error in our logs:

c.r.c.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - delivery acknowledgement on channel 5 timed out. Timeout value used: 1800000 ms. This timeout value can be configured, see consumers doc guide to learn m...

After this statement (presumably logged by this statement), the channel is promptly shut down, the Reactive Flux is terminated and message processing stops consequently.

The client has been configured with a retry ack exception handler in an attempt to mitigate connection failures:

    Receiver receiver = RabbitFlux.createReceiver();

    ConsumeOptions consumeOptions = new ConsumeOptions()
        .exceptionHandler(new ExceptionHandlers.RetryAcknowledgmentExceptionHandler(
            Duration.ofSeconds(10), 
            Duration.ofMillis(200),
            ExceptionHandlers.CONNECTION_RECOVERY_PREDICATE
        ));

    receiver.consumeManualAck("queue_name", consumeOptions)
        .subscribe(delivery -> {
            // message processing omitted
            // acknowledge message
            delivery.ack();
        });

However, we must have overlooked something as the problem is still observed from time to time.

Desired solution

A documented way for the Receiver or Flux to recover from Acknowledgement timeouts similar to the one described above.

Considered alternatives

• A similar question as the one above has been posted to Stack Overflow.
• An answer to a different Stack Overflow question suggests that it is possible to change the Acknowledgement timeout. However, that would change the frequency of this problem without solving the root cause.
• Unclear how to keep the consumer open after an exception is thrown #177 if addressed could possibly provide a solution as it describes the more generic problem of keeping a consumer open when any exception occurs.