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.
Add lag-based wait for future-version OFFLINE->STANDBY transition #2976
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
Add lag-based wait for future-version OFFLINE->STANDBY transition #2976
Changes from all commits
02338e7File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
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.
This loop synchronously sleeps on the Helix state-transition executor. With the defaults, each lagging partition can hold one worker for up to 120 minutes.
VeniceServerConfigstill defaultsLEADER_FOLLOWER_STATE_TRANSITION_THREAD_POOL_STRATEGYtoSINGLE_POOL_STRATEGY(20 workers), so enough concurrent future-version transitions could delay current or backup-version transitions as well.What is the current rollout/adoption of
DUAL_POOL_STRATEGYin production? Is enabling this lag check intended to be coupled with the dual-pool rollout? If some clusters still use the single pool, should we validate or reject that configuration combination, or otherwise avoid holding a transition worker while polling? Even with dual pool, it would be useful to understand expected concurrency versus the default future-version pool size.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.
Could we restrict this wait to an explicitly active future-version push, e.g.
version.getStatus() == VersionStatus.STARTED, rather than using "future and notPUSHED/ONLINE" as the proxy?isFutureVersionReady()is false for terminal states such asKILLED,ERROR, andROLLED_BACK. Those states can overlap with anOFFLINE -> STANDBYcallback because killing and Helix-resource cleanup are asynchronous: the transition may already be running or queued when the version is markedKILLED. In the normal kill path the ingestion task will eventually clear its PCS, so this wait should fail open on a later poll, but it can still occupy the transition worker until that poll; delayed kill or cleanup can extend this to the timeout.It would also be useful to re-check the status while polling, since a push can be
STARTEDwhen the wait begins and becomeKILLEDorERRORafterward.Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.