-
Notifications
You must be signed in to change notification settings - Fork 3.8k
[fix][broker] Debit only credited permits when removing a Shared consumer #26417
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
Closed
FlorentinDUBOIS
wants to merge
3
commits into
apache:master
from
FlorentinDUBOIS:repro/shared-permits-negative-aggregate
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
bf84c67
[improve][test] Add Shared subscription available-permits invariant t…
FlorentinDUBOIS b3cd75c
[fix][broker] Debit un-acked messages only when the consumer is actua…
FlorentinDUBOIS a03a950
[fix][broker] Debit only credited permits when removing a Shared cons…
FlorentinDUBOIS File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Please handle
elselogic, which should re-compute unacked message.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.
Thanks for the review! I did consider recomputing in the
elsebranch and concluded the counter must not be touched there.totalUnackedMessagesis maintained in lockstep with the per-consumer counters: every mutation goes throughConsumer#addAndGetUnAckedMsgs(Consumer.java:1298) orConsumer#clearUnAckedMsgs(Consumer.java:1314), each applying the same delta to the consumer's counter and tosubscription.addUnAckedMessages(...). The one place the subscription counter moves without the consumer counter is the debit inremoveConsumer, which settles the departing consumer exactly once, at unregistration.The
elsebranch fires only whenconsumerSet.removeAll(consumer) == 0. SinceaddConsumeralways inserts into both collections andconsumerSetis anObjectHashSet(AbstractDispatcherMultipleConsumers.java:35), the #22270 mismatch can only be a leftoverconsumerListduplicate whose contribution the first removal already debited. Debiting again there is exactly the double-accounting on master this PR fixes, and a recompute would be a guaranteed no-op.A recompute is also not safely expressible for this counter, unlike permits: every delta must flow through
addUnAckedMessages, which forwards it to the broker-level aggregate (line 1242) and drives the blocked-dispatcher hysteresis, so the field cannot be set directly; and summingconsumerListwould count duplicates twice and re-add the departed consumer's stale, never-zeroed counter. Permits needrecomputeTotalAvailablePermits()only because their lockstep is intentionally broken —internalConsumerFlowdrops flow from unregistered consumers — while the unacked lockstep is fenced by the closedpendingAcksmap.I can add a short comment in the
elsebranch documenting this invariant if you think it helps — happy to discuss further.