TransportListTaskAction: wait for tasks to finish asynchronously#90977
TransportListTaskAction: wait for tasks to finish asynchronously#90977arteam merged 20 commits intoelastic:mainfrom
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 |
kingherc
left a comment
There was a problem hiding this comment.
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.
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.
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.
DaveCTurner
left a comment
There was a problem hiding this comment.
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 |
fcofdez
left a comment
There was a problem hiding this comment.
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
nodeOperationafter 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