fixes #236: Shard starvation under some circumstances #237
Conversation
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
astubbs
added a commit
to astubbs/parallel-consumer
that referenced
this pull request
Mar 22, 2022
…nfluentinc#237) The simplest scenario of this issue, is: using PARTITION ordering max concurrency set to 2 - consumer is able to poll 10 messages, the first 5 for partition 0, the next 5 for partition 1 - when PC requests work from work manager, it first requests 2 work units - work manager then ingests 2 units from it's queue, but to shard partition 0 - then shard iteration begins, partition order restriction is set, so only takes a single entry from the ONLY partition shard of zero - so result is only a single record is returned, even through there are 5 in the queue for the 2nd partition that aren't "realised" - on next request to WM, 1 more unit is requested to hit concurrency target - and this is also ingested from the 3 remaining for partition 0, and the rest for partition 1 are still undiscovered, and so on and so on - extrapolate out... - solution: - ingest the entire work queue into shards every round, which is effectively also what confluentinc#219 Also fixed by upcoming RR: refactor: Queue unification confluentinc#219
The simplest scenario of this issue, is: using PARTITION ordering max concurrency set to 2 - consumer is able to poll 10 messages, the first 5 for partition 0, the next 5 for partition 1 - when PC requests work from work manager, it first requests 2 work units - work manager then ingests 2 units from it's queue, but to shard partition 0 - then shard iteration begins, partition order restriction is set, so only takes a single entry from the ONLY partition shard of zero - so result is only a single record is returned, even through there are 5 in the queue for the 2nd partition that aren't "realised" - on next request to WM, 1 more unit is requested to hit concurrency target - and this is also ingested from the 3 remaining for partition 0, and the rest for partition 1 are still undiscovered, and so on and so on - extrapolate out... - solution: - ingest the entire work queue into shards every round, which is effectively also what #219 Also fixed by upcoming RR: refactor: Queue unification #219
PriorityQueue only provides a sorted `poll`, whereas TreeSet iterates in sorted order.
astubbs
force-pushed
the
bugs/shard-starvation
branch
from
4414fd7 to
21b7a1b
Compare
|
Redundantly fixed by: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
see:
made redundant by: