Link child requests to the root task that initiated the action #48422
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
This commit modifies the hierarchy of tasks to link any child requests executed by a transport action to the root task that initiated the request. For instance today a shard search is linked to the main search task that coordinate the entire request. However if the main search task was created by a multi search action, multiple roundtrips are needed to link the multi search to the shard searches that it creates (by recursively checking the parent of the tasks). This is not convenient when cancelling a task since it requires to send the cancellation for the root task first, then to all nodes to cancel the child task and recursively until there is no more child tasks. Currently we only handle one level so multi _search cancellation cannot reach the grand-children (the shard search). The proposal in this change is to always link child tasks to their root task (the task that initiated the original action). While the change is simple it might be considered as breaking since we loose the association between children and grand-children so it would not be possible to cancel an individual search without cancelling the entire msearch action. I think it's an acceptable trade-off mainly because other solutions that would not break this behavior would require much more changes. We could for instance keep the full list of parents for a specific task but that would require to change all the call to execute a task locally. Another solution would be to add more roundtrips to task cancellations but that's also a big change that would complicate cancellation significantly.
jimczi
added
>enhancement
>breaking
:Search/Search
Collaborator
|
Pinging @elastic/es-search (:Search/Search) |
Collaborator
|
Pinging @elastic/es-distributed (:Distributed/Task Management) |
Contributor
Author
We discussed another route offline, for reindex there are discussions around a new mechanism to allow cancelling only the root task. For msearch we should use a header and add the ability to cancel a task from its |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This commit modifies the hierarchy of tasks to link any child requests executed
by a transport action to the root task that initiated the request. For instance today
a shard search is linked to the main search task that coordinate the entire request.
However if the main search task was created by a multi search action, multiple roundtrips
are needed to link the multi search to the shard searches that it creates (by recursively checking the parent of the tasks).
This is not convenient when cancelling a task since it requires to send the cancellation for the root task first, then to all nodes to cancel the child task and recursively until there is no more child tasks. Currently we only handle one level so multi_search cancellation cannot reach the grand-children (the shard search).
The proposal in this change is to always link child tasks to their root task (the task that initiated the original action). While the change is simple it might be considered as breaking since we loose the association between children and grand-children so it would not be possible to cancel an individual search without cancelling the entire msearch action.
I think it's an acceptable trade-off mainly because other solutions that would not break this behavior would require much more changes.
We could for instance keep the full list of parents for a specific task but that would require to change all the call to execute a task locally.
Another solution would be to add more roundtrips to task cancellations but that's also a big change that would complicate cancellation significantly.
I didn't change the documentation around cancellation yet since this change might be controversial. Let's discuss it here and we can add documentation if we reach a consensus.