Describe the bug
We’re experiencing an intermittent issue where message consumers on a queue silently disappear (0 consumers visible in the RabbitMQ Management UI) while messages remain in the "Ready" state. The issue resolves itself after restarting the pod hosting the application.
This behavior has occurred multiple times in our environment running:
spring-amqp:3.2.5
com.rabbitmq:amqp-client:5.22.0
- Running in a Kubernetes (K8s) environment
After reviewing related issues:
- https://stackoverflow.com/questions/48699178/spring-amqp-client-hangs
- https://github.com/spring-projects/spring-amqp/issues/1241
- https://stackoverflow.com/questions/63465726/pcf-rabbitmq-unacked-messages-in-queue
I suspect this might be connected either to Spring AMQP’s listener container recovery logic or the Java client’s topology recovery behavior.
Expected behavior
The consumers should remain connected, or automatically recover in case of network or broker issues without requiring a pod/application restart.
Questions:
- Could this be a bug in the Spring AMQP 3.2.5 listener container’s recovery logic when paired with
amqp-client:5.22.0
? - Would upgrading to a newer
amqp-client
(e.g., 5.23.0) be advisable, or is a fix required at the Spring AMQP level?
Environment
Component | Version |
---|---|
Spring AMQP | 3.2.5 |
com.rabbitmq\:amqp-client | 5.22.0 |
Spring Boot | 3.4.5 |
Comment From: artembilan
Any chances to have some simple project to reproduce on our side? Any chances to reproduce it outside of Kubrrnetes?
I mean there are so many variables, that not clear from where to start. Might be the case that health check returns false in case of that network glitch, so Kubrrnetes decides to stop that pod. Therefore no chance for recovery to be performed in the application .
Comment From: srijan-singh
Sure — I’ll try to re-create the scenario in a simple standalone project outside of Kubernetes and see if I can reproduce the issue there.
Comment From: srijan-singh
Unable to re-produce the issue outside of Kubernetes, thus closing the issue.