-
Notifications
You must be signed in to change notification settings - Fork 25k
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
TransportGetTaskAction: Wait for the task asynchronously #93375
Conversation
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.
Nice work 😄
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
Show resolved
Hide resolved
.../main/java/org/elasticsearch/action/admin/cluster/node/tasks/get/TransportGetTaskAction.java
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 |
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, 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 <[email protected]>
@elasticmachine update branch |
@@ -152,6 +152,10 @@ | |||
- set: {task: task} | |||
|
|||
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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) |
@@ -152,6 +152,10 @@ | |||
- set: {task: task} | |||
|
|||
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
@@ -128,7 +128,7 @@ public void testWaitForCompletion() throws Exception { | |||
})); | |||
|
|||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
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 😄
Wait for the requested task asynchronously in a similar fashion to
TransportListTaskAction
from #90977See #90977