Skip to content
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

Conversation

DaveCTurner
Copy link
Contributor

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.

Relates #41536.

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.
@DaveCTurner DaveCTurner added >bug :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. labels Jul 5, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@DaveCTurner DaveCTurner requested a review from ywelsch July 5, 2019 08:35
Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@DaveCTurner DaveCTurner merged commit d016e79 into elastic:peer-recovery-retention-leases Jul 5, 2019
@DaveCTurner DaveCTurner deleted the 2019-07-05-recovery-on-generic-thread branch July 5, 2019 11:04
DaveCTurner added a commit that referenced this pull request Jul 5, 2019
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());
Copy link
Member

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(...).

DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this pull request Jul 5, 2019
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.
DaveCTurner added a commit that referenced this pull request Jul 8, 2019
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.
DaveCTurner added a commit that referenced this pull request Jul 8, 2019
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants