Repository navigation
fixes #236: Shard starvation under some circumstances - #237
Closed
Antony Stubbs (astubbs) wants to merge 7 commits into
Closed
Antony Stubbs (astubbs) wants to merge 7 commits into
Antony Stubbs (astubbs) wants to merge 7 commits into
Conversation
Antony Stubbs (astubbs)
referenced
this pull request
in astubbs/parallel-consumer
Mar 22, 2022
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
Antony Stubbs (astubbs)
force-pushed
the
master
branch
from
March 23, 2022 13:49
3905c7c to
3dcb9d7
Compare
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.
Antony Stubbs (astubbs)
force-pushed
the
bugs/shard-starvation
branch
from
April 7, 2022 08:53
4414fd7 to
21b7a1b
Compare
Contributor
Author
|
Redundantly fixed by: |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: