-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Poison handling in quorum queues #1889
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
Looks generally fine but it needs to be tested through |
e65ad0f
to
e9ccbe4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When reaching the delivery_limit
this code only avoids adding it back to the returns queue. It also needs to remove it from the index and the consumer's checked_out map. Probably best to use the complete
function in some way or other.
Also needs eunit tests for this feature.
b604bb3
to
f358b89
Compare
Drop messages that exceed the configured number of delivery attemps. If a DLX is configured, dead letter them. [#163513253]
[#163513253]
By ensuring the delivery count is retained when "dehydrating" the state in preparation for snapshotting. Now the entire message header map is stored which will take additional space w.r.t to keynamne duplication although this can be optimised. Also updated the property test to generate fake pids for multiple nodes so that multi node scenarios are better covered. [#163513253]
So that nodeups also can stand a chance to be tested
affdbf9
to
99ee5fb
Compare
To keep all static and rarely changed data in a nested sub-structure. This will reduce gc pressure somewhat. [#163513253]
Called `delivery_limit` [#163513253]
…queues (Tobion) This PR was merged into the 4.3 branch. Discussion ---------- [Messenger] prevent infinite redelivery loops and blocked queues | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | Fix #32055 | License | MIT | Doc PR | This PR solves a very common fitfall of amqp redeliveries. It's for example explained in https://blog.forma-pro.com/rabbitmq-redelivery-pitfalls-440e0347f4e0 Newer RabbitMQ versions provide a solution for this by itself but only for quorum queues and not the classic ones, see rabbitmq/rabbitmq-server#1889 This PR adds a middleware that throws a RejectRedeliveredMessageException when a message is detected that has been redelivered by AMQP. The middleware runs before the HandleMessageMiddleware and prevents redelivered messages from being handled directly. The thrown exception is caught by the worker and will trigger the retry logic according to the retry strategy. AMQP redelivers messages when they do not get acknowledged or rejected. This can happen when the connection times out or an exception is thrown before acknowledging or rejecting. When such errors happen again while handling the redelivered message, the message would get redelivered again and again. The purpose of this middleware is to prevent infinite redelivery loops and to unblock the queue by republishing the redelivered messages as retries with a retry limit and potential delay. Commits ------- d211904 [Messenger] prevent infinite redelivery loops and blocked queues
Proposed Changes
Drop messages that exceed the configured number of delivery attempts.
If a DLX is configured, dead letter them.
Part of #502.
Types of Changes
Checklist
CONTRIBUTING.md
document