Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container Listener Starts Up Even If Binding Decalaration Fails #1324

Open
nnesic opened this issue Apr 16, 2021 · 1 comment
Open

Container Listener Starts Up Even If Binding Decalaration Fails #1324

nnesic opened this issue Apr 16, 2021 · 1 comment

Comments

@nnesic
Copy link

nnesic commented Apr 16, 2021

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.

@garyrussell
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants