-
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
Return recovery to generic thread post-PRRL action #44000
Return recovery to generic thread post-PRRL action #44000
Conversation
Today we perform `TransportReplicationAction` derivatives during recovery, and these actions call their response handlers on the transport thread. This change moves the continued execution of the recovery back onto the generic threadpool.
Pinging @elastic/es-distributed |
server/src/main/java/org/elasticsearch/indices/recovery/RecoverySourceHandler.java
Outdated
Show resolved
Hide resolved
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
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.
Today we perform `TransportReplicationAction` derivatives during recovery, and these actions call their response handlers on the transport thread. This change moves the continued execution of the recovery back onto the generic threadpool.
@@ -144,8 +146,10 @@ public void recoverToTarget(ActionListener<RecoveryResponse> listener) { | |||
IOUtils.closeWhileHandlingException(releaseResources, () -> wrappedListener.onFailure(e)); | |||
throw e; | |||
}); | |||
final Consumer<Exception> onFailure = e -> | |||
final Consumer<Exception> onFailure = e -> { | |||
Transports.assertNotTransportThread("failure of recovery from " + shard.routingEntry() + " to " + request.targetNode()); |
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 think this should be assert Transports.assertNotTransportThread(...)
.
In elastic#44000 we introduced some calls to `assertNotTransportThread` that are executed whether assertions are enabled or not. Although they have no effect if assertions are disabled, we should have done it like this instead.
In #44000 we introduced some calls to `assertNotTransportThread` that are executed whether assertions are enabled or not. Although they have no effect if assertions are disabled, we should have done it like this instead.
In #44000 we introduced some calls to `assertNotTransportThread` that are executed whether assertions are enabled or not. Although they have no effect if assertions are disabled, we should have done it like this instead.
Today we perform
TransportReplicationAction
derivatives during recovery, andthese actions call their response handlers on the transport thread. This change
moves the continued execution of the recovery back onto the generic threadpool.
Relates #41536.