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

Don't block on peer recovery on the target side #37076

Merged
merged 8 commits into from
Jan 4, 2019

Conversation

s1monw
Copy link
Contributor

@s1monw s1monw commented Jan 2, 2019

Today we block using the generic thread-pool on the target side
until the source side has fully executed the recovery. We still
block on the source side executing the recovery in a blocking fashion
but there is no reason to block on the target side. This will
release generic threads early if there are many concurrent recoveries
happen.

Relates to #36195

Today we block using the generic threadpool on the target side
until the source side has fully executed the recovery. We still
block on the source side executing the recovery in a blocking fashion
but there is no reason to block on the target side. This will
release generic threads early if there are many concurrent recoveries
happen.

Relates to elastic#36195
@s1monw s1monw added >enhancement :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. v7.0.0 v6.7.0 labels Jan 2, 2019
@s1monw s1monw requested review from ywelsch and DaveCTurner January 2, 2019 15:12
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@s1monw s1monw requested a review from bleskes January 2, 2019 15: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.

The response handler will need to run under GENERIC as both the happy and the retry/fail path do expensive blocking calls. As a follow-up, we can investigate whether we can get rid of RecoveryTarget.cancellableThreads.

@s1monw
Copy link
Contributor Author

s1monw commented Jan 3, 2019

@DaveCTurner @ywelsch I pushed changes

@s1monw
Copy link
Contributor Author

s1monw commented Jan 3, 2019

folks I added back the cancelableThreads for now, I am not 100% convinced it's not needed and I would like to investigate it in a followup. I will also try to remove it entirely from the RecoveryTarget as @ywelsch suggested. Yet, give how delicate the place of this call is I would like to only do it in 7.0 and only if we don't see issues backport it maybe later.

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.

Yet, give how delicate the place of this call is I would like to only do it in 7.0 and only if we don't see issues backport it maybe later

++

@s1monw s1monw merged commit b4f113d into elastic:master Jan 4, 2019
s1monw added a commit that referenced this pull request Jan 4, 2019
Today we block using the generic thread-pool on the target side
until the source side has fully executed the recovery. We still
block on the source side executing the recovery in a blocking fashion
but there is no reason to block on the target side. This will
release generic threads early if there are many concurrent recoveries
happen.

Relates to #36195
kovrus added a commit to crate/crate that referenced this pull request Sep 11, 2019
kovrus added a commit to crate/crate that referenced this pull request Sep 11, 2019
kovrus added a commit to crate/crate that referenced this pull request Sep 12, 2019
kovrus added a commit to crate/crate that referenced this pull request Sep 12, 2019
kovrus added a commit to crate/crate that referenced this pull request Sep 12, 2019
mergify bot pushed a commit to crate/crate that referenced this pull request Sep 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. >enhancement v6.7.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants