TransportGetTaskAction: Wait for the task asynchronously#93375
TransportGetTaskAction: Wait for the task asynchronously#93375arteam merged 25 commits intoelastic:mainfrom
Conversation
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
Outdated
Show resolved
Hide resolved
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
Outdated
Show resolved
Hide resolved
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
Outdated
Show resolved
Hide resolved
938eb31 to
a3c20f3
Compare
|
@elasticmachine update branch |
DaveCTurner
left a comment
There was a problem hiding this comment.
Looks good, now it just needs a test 😁
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
Outdated
Show resolved
Hide resolved
…de/tasks/get/TransportGetTaskAction.java Co-authored-by: David Turner <david.turner@elastic.co>
|
@elasticmachine update branch |
| - do: | ||
| # Inherits the warning from the previous task | ||
| warnings: | ||
| - The sort option in reindex is deprecated. Instead consider using query |
There was a problem hiding this comment.
It looks like with the latest change getTask now inherits warnings from the previous task (not sure why it wasn't the case with a blocking call in the generic pool?) which is technically is a breaking change :(
There was a problem hiding this comment.
I suspect this is because we call the RemovedTaskListener (and therefore complete the future) in the thread context of the task that's being removed. We need to fix that, we can't just leak context across responses like this.
|
Hi @arteam, I've created a changelog YAML for you. |
|
Pinging @elastic/es-distributed (Team:Distributed) |
| - do: | ||
| # Inherits the warning from the previous task | ||
| warnings: | ||
| - The sort option in reindex is deprecated. Instead consider using query |
There was a problem hiding this comment.
I suspect this is because we call the RemovedTaskListener (and therefore complete the future) in the thread context of the task that's being removed. We need to fix that, we can't just leak context across responses like this.
| // The task has already finished, we can run the completion listener in the same thread | ||
| waitedForCompletionListener.onResponse(null); | ||
| } else { | ||
| future.addListener(waitedForCompletionListener); |
There was a problem hiding this comment.
... like this
| future.addListener(waitedForCompletionListener); | |
| future.addListener( | |
| ContextPreservingActionListener.wrapPreservingContext(waitedForCompletionListener, threadPool.getThreadContext()) | |
| ); |
We also need to do this for the list-tasks action, and ideally we'd have a test for it there too.
There was a problem hiding this comment.
Ah sorry this was wrong, when we wrap it like this the response headers will still propagate. We have to do it like this to drop the response headers:
new ContextPreservingActionListener<>(threadPool.getThreadContext().newRestorableContext(false), waitedForCompletionListener)
…de/tasks/get/TransportGetTaskAction.java Co-authored-by: David Turner <david.turner@elastic.co>
|
|
||
| // briefly fill up the generic pool so that (a) we know the wait has started and (b) we know it's not blocking | ||
| // flushThreadPool(threadPool, ThreadPool.Names.GENERIC); // TODO it _is_ blocking right now!!, unmute this in #93375 | ||
| flushThreadPool(threadPool, ThreadPool.Names.GENERIC); |
There was a problem hiding this comment.
Hm now that I look at this again, with these changes we're not using the GENERIC pool any more (indeed there's no forking at all when waiting for completion) so this line doesn't make sense. We can just drop this (and therefore inline flushThreadPool at its only other call-site).
|
Just a couple of outstanding comments here but I'd quite like to get this in today @arteam - let us know if you won't have capacity and I'll find some elsewhere. |
|
@DaveCTurner I spent some time looking at it on Thursday, but becase the Using |
|
Hmm, it seems to work for me? I pushed the fix I think we need, let's see what I'm missing in CI. I think we don't need the |
|
Thank you! I missed the comment about using |
Wait for the requested task asynchronously in a similar fashion to
TransportListTaskActionfrom #90977See #90977