-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Recover bindings for all durable queues including failed to recover. #1878
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
Conversation
If a queue fails to recover it may still be restarted by the supervisor and eventually start. After that some bindings may be in rabbit_durable_route but not rabbit_route. This can cause binding not found errors. If bindings are recovered for failed queues, the behaviour will be the same as for the crashed queues. (which is currently broken but needs to be fixed separately) Addresses #1873 [#163919158]
Separate PR for 3.7 |
ah, solving this weird case https://groups.google.com/forum/#!topic/rabbitmq-users/-X19dq8cYaY thank you! 👍 |
@Ayanda-D we don't yet know and would not claim it is sufficient because there was no reliable way to reproduce any of those reports :( |
@michaelklishin ok, this was reported to us as well, but haven't been able to to reproduce it either :/ seemed the error handling could be improved as well? When binding lookup in |
@Ayanda-D this PR will fix The option to allow recovery of bindings does also make sense. I was thinking of letting |
Ok, sounds good 👍 |
If a queue fails to recover it may still be restarted by the supervisor
and eventually start. After that some bindings may be in rabbit_durable_route
but not rabbit_route. This can cause binding not found errors.
If bindings are recovered for failed queues, the behaviour will be
the same as for the crashed queues. (which is currently broken
but needs to be fixed separately)
Addresses #1873
[#163919158]
This will reqruire a separate PR for 3.7