How to robustly handle delivery acknowledgement timeout #12443
-
Community Support Policy
RabbitMQ version used4.0.2 Use case descriptionI'm using https://github.com/mosquito/aio-pika to build an RabbitMQ based application where queues use delivery acknowledgement timeouts. When timeout occur I get the following (and expected) error:
However, since I'm using aiopika's This happens because when the channel is closed, I would like to change that behavior so that the channel is not re-open when a consumer timeout occurred, however I'm left with the following question How to robustly identify delivery acknowledgment timeout when it occurs ?Looking at the server code I see that a generic From the client perspective how can I distinguish/isolate the consumer timeout case from other I'm tempted to parse the error message, however can I have strong guarantees that it will be stable across non breaking version of the rabbitMQ server ? What strategy do you advise to robustly isolate consumer timeouts when it happens ? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
In general, if you get a consumer timeout, the opinion of Team RabbitMQ is that your application has a bug. In this case, you will have to parse the error message.
The message probably won't change. I'm not sure if we have the option for a different AMQP error to be returned in this case (cc @michaelklishin ?) |
Beta Was this translation helpful? Give feedback.
In general, if you get a consumer timeout, the opinion of Team RabbitMQ is that your application has a bug.
In this case, you will have to parse the error message.
The message probably won't change. I'm not sure if we have the option for a different AMQP error to be returned in this case (cc @michaelklishin ?)