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(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:
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.
177 if addressed could possibly provide a solution as it describes the more generic problem of keeping a consumer open when any exception occurs.
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:
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:
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
177 if addressed could possibly provide a solution as it describes the more generic problem of keeping a consumer open when any exception occurs.