rhythm: fair partition consumption #4655
Merged
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
|
HI, Javi. You have the docs box checked in the description but I don't see any. Are you working on docs for this? |
My bad, I clicked all of them |
mdisibio
reviewed
Feb 10, 2025
javiermolinar
commented
Feb 14, 2025
mapno
reviewed
Feb 17, 2025
mapno
reviewed
Feb 20, 2025
There was a problem hiding this comment.
I'm ok with these changes. I'll approve when this discussion is resolved
|
+1 changes lgtm but defer to the rest of the team for final approval. |
mapno
approved these changes
Feb 21, 2025
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.
What this PR does:
The current loop has two drawbacks. The first one is that it keeps consuming from a single partition while it has a record, neglecting the others. This is not a problem right now since every blockbuilder is in charge of a single partition. The second problem is the main run loop; after consuming a complete cycle (that can take much more than the consuming cycle due to the first drawback), it waits another fixed time, incrementing the lag.
This PR tries to tackle this by first prioritizing the partitions with more lag. For that, we get first the lag in time for every partition. We continue consuming from the laggiest partition until the lag is less than the cycle time.
The number of FetchOffsetsForTopics and ListEndOffsets requests has been reduced now to only one request per cycle instead of one request for every partition cycle
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]