-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Threadpool merge executor does not block aborted merges #129613
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’ll 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?
Threadpool merge executor does not block aborted merges #129613
Conversation
Hi @albertzaharovits, I've created a changelog YAML for you. |
// update the per-element budget (these are all the elements that are using any budget) | ||
// updates the budget of enqueued elements (and possibly reorders the priority queue) | ||
updateBudgetOfEnqueuedElementsAndReorderQueue(); | ||
// update the budget of dequeued, but still in-use elements (these are the elements that are consuming budget) | ||
unreleasedBudgetPerElement.replaceAll((e, v) -> budgetFunction.applyAsLong(e.element())); |
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 change will also adjust the budget of running merges that have been aborted to 0
. That's a bit optimistic, but I find the alternative implementation convoluted, and it's probably counter-intuitive to estimate 0
for to-be-run merges but not for already-running ones.
This PR addresses a bug where aborted merges are blocked if there's insufficient disk space.
Previously, the merge disk space estimation did not consider if the operation has been aborted when/while it was enqueued for execution. Consequently, aborted merges, for e.g. when closing a shard, were blocked if their disk space estimation was exceeding the available disk space threshold. In this case, the shard close operation would itself block.
This fix estimates a disk space budget of
0
for aborted merges, and it periodically checks if any enqueued merge tasks have been aborted (more generally, it checks if the budget estimate for any merge tasks has changed, and reorders the queue if so). This way aborted merges are prioritized and are never blocked.Fixes #129335