You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently had an issue with Rabbitmq in Kubernetes with mirrored queues. Rabbit pods crashed, and while they were recovering, my Spring app tried to reconnect and declare its queues and bindings, which messed up Rabbitmq and it kept running in a weird state in which the queue existed, but all of its bindings and messages were gone, and any attempt to declare the bindings resulted in an error.
The errors on binding declaration are a bug in Rabbitmq itself I believe. I will try moving away from mirrored queues and see if that helps.
However, my Spring application did not consider binding failures to be critical enough to abort startup. It resulted in a consumer that was successfully listening to the queue, which existed, but never received any messages because, missing the bindings, no messages were routed to it from my exchange. The consumer restart was also never prompted because the connection and channel were ok.
I was digging through the code, and I saw that the SimpleMessageListenerContainer does allow Mismatched Queues to cause a fatal failure (if I understood the code correctly). I was wondering if it would be ok to add a similar config which, if set to true, would re-throw any queue binding related exceptions, so that we don't have a listener on a queue that hasn't been propperly set up?
Thanks.
The text was updated successfully, but these errors were encountered:
I don't know how practical that would be from a framework perspective; consumers only know about queues; they know nothing about any of the upstream topology (exchanges, bindings).
If the binding declaration fails silently, I think the only thing that could be done is to use the REST API (rabbitmq-http - Hop client) to inspect the bindings - bear in mind, though, it's not real time and it takes a few seconds to show up after the declaration.
If the channel.queueBind() method throws an exception, you could add an @EventListener method (or an ApplicationListener<DeclarationExceptionEvent>) to listen for DeclarationExceptionEvents and take whatever action you need to.
Hello.
I recently had an issue with Rabbitmq in Kubernetes with mirrored queues. Rabbit pods crashed, and while they were recovering, my Spring app tried to reconnect and declare its queues and bindings, which messed up Rabbitmq and it kept running in a weird state in which the queue existed, but all of its bindings and messages were gone, and any attempt to declare the bindings resulted in an error.
The errors on binding declaration are a bug in Rabbitmq itself I believe. I will try moving away from mirrored queues and see if that helps.
However, my Spring application did not consider binding failures to be critical enough to abort startup. It resulted in a consumer that was successfully listening to the queue, which existed, but never received any messages because, missing the bindings, no messages were routed to it from my exchange. The consumer restart was also never prompted because the connection and channel were ok.
I was digging through the code, and I saw that the SimpleMessageListenerContainer does allow Mismatched Queues to cause a fatal failure (if I understood the code correctly). I was wondering if it would be ok to add a similar config which, if set to true, would re-throw any queue binding related exceptions, so that we don't have a listener on a queue that hasn't been propperly set up?
Thanks.
The text was updated successfully, but these errors were encountered: