-
Notifications
You must be signed in to change notification settings - Fork 24.7k
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
TransportListTaskAction: wait for tasks to finish asynchronously #90977
TransportListTaskAction: wait for tasks to finish asynchronously #90977
Conversation
2f1e118
to
cff6350
Compare
@elasticmachine update branch |
f82b7ea
to
3e9edef
Compare
Hi @arteam, I've created a changelog YAML for you. |
Pinging @elastic/es-distributed (Team:Distributed) |
Hi @arteam, I've updated the changelog YAML for you. |
Hi @arteam, I've updated the changelog YAML for you. |
@elasticmachine update branch |
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.
Looks good to me so far! Just left a couple of comments before approving, to see if a couple of questions I have (due to my inexperience with this part of the code) are already done or need further attention.
|
||
@Override | ||
public void subscribeForRemovedTasks(RemovedTaskListener removedTaskListener) { | ||
waitForWaitingToStart.countDown(); |
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.
Do we need any additional tests for the new feature added in this PR or are the existing tests already indirectly testing the new feature?
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.
I believe we worked around this by always having 2 MANAGEMENT threads in #90193. I think we would get sufficient coverage by reverting that change, and we should do that here.
...in/java/org/elasticsearch/action/admin/cluster/node/tasks/list/TransportListTasksAction.java
Outdated
Show resolved
Hide resolved
…astic#90214)" This reverts commit 50cf18e.
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.
Looks good, I left just a couple more nits. I'd like someone else to review too tho.
...in/java/org/elasticsearch/action/admin/cluster/node/tasks/list/TransportListTasksAction.java
Outdated
Show resolved
Hide resolved
...in/java/org/elasticsearch/action/admin/cluster/node/tasks/list/TransportListTasksAction.java
Outdated
Show resolved
Hide resolved
@elasticmachine update branch |
@elasticmachine update branch |
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.
LGTM, I left a couple of naming suggestions. I wonder if we could simplify this logic by changing how the subclasses interact with the task collection, etc. But I guess that route has been considered already.
In elastic#90977 we made the list tasks API fully async, but failed to notice that if we waited for a task to complete then we would respond in the thread context of the last-completing task. This commit fixes the problem by restoring the context of the list-tasks task before responding. Closes elastic#93428
In elastic#90977 we made the list tasks API fully async, but failed to notice that if we waited for a task to complete then we would respond in the thread context of the last-completing task. This commit fixes the problem by restoring the context of the list-tasks task before responding. Closes elastic#93428
Instead of synchronously blocking a thread in the management pool, add a listener on removed tasks and calls
nodeOperation
after all matched tasks have been removed. Also add a scheduled tasks to bail out after the specified wait timeout if the tasks haven't been finished.Fixes #89564, #90988