Refactor poller tracking from tasklist to poller package #6777
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
Shaddoll
reviewed
Apr 2, 2025
service/matching/poller/manager.go
Outdated
| StartPoll(pollerID string, cancelFunc context.CancelFunc, info *Info) | ||
| EndPoll(pollerID string) | ||
| CancelPoll(pollerID string) bool | ||
| HasGroupAfter(isolationGroup string, earliest time.Time) bool |
There was a problem hiding this comment.
HasPollerFromIsolationGroupAfter is a better name
Shaddoll
reviewed
Apr 2, 2025
service/matching/poller/manager.go
Outdated
| EndPoll(pollerID string) | ||
| CancelPoll(pollerID string) bool | ||
| HasGroupAfter(isolationGroup string, earliest time.Time) bool | ||
| HasAnyAfter(after time.Time) bool |
There was a problem hiding this comment.
HasPollerAfter is a better name, I think
Shaddoll
approved these changes
Apr 2, 2025
Address a longstanding TODO, moving outstanding poller tracking to the poller package. This simplifies task_list_manager and consolidates outstanding poller tracking with the poller history. Improve the calculation of whether there are recent pollers for a given isolation group. Currently we calculate the number of pollers for every isolation group and then check whether the value for a given isolation group is greater than zero. This requires iterating through the entire recent pollers cache. Given it has a maximum size of 5000, this isn't a great thing to do for every single task we dispatch. Instead we can store the number of outstanding pollers by group and the last time a poll for the group ended, making it a consistently quick check. Additionally optimize HasAnyAfter to use a similar mechanism, although the frequency at which that is used makes that less important. Fix the double counting of getRecentPollersByIsolationGroup by tracking in the poller history whether a poller is outstanding. Currently we iterate through the poller history then through the outstanding pollers, but if a poller began its poll within the TaskIsolationPollerWindow it gets counted twice. The accuracy of this function isn't particularly important, but we should err on the side of correctness.
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.
Address a longstanding TODO, moving outstanding poller tracking to the poller package. This simplifies task_list_manager and consolidates outstanding poller tracking with the poller history.
Improve the calculation of whether there are recent pollers for a given isolation group. Currently we calculate the number of pollers for every isolation group and then check whether the value for a given isolation group is greater than zero. This requires iterating through the entire recent pollers cache. Given it has a maximum size of 5000, this isn't a great thing to do for every single task we dispatch. Instead we can store the number of outstanding pollers by group and the last time a poll for the group ended, making it a consistently quick check.
Additionally optimize HasAnyAfter to use a similar mechanism, although the frequency at which that is used makes that less important.
Fix the double counting of getRecentPollersByIsolationGroup by tracking in the poller history whether a poller is outstanding. Currently we iterate through the poller history then through the outstanding pollers, but if a poller began its poll within the TaskIsolationPollerWindow it gets counted twice. The accuracy of this function isn't particularly important, but we should err on the side of correctness.
What changed?
Why?
How did you test it?
Potential risks
Release notes
Documentation Changes