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

Remove unneeded waits on recovery cancellation #7717

Closed
wants to merge 3 commits into from

Conversation

bleskes
Copy link
Contributor

@bleskes bleskes commented Sep 15, 2014

When cancelling recoveries, we wait for up to 10s for the source node to be notified before continuing. This is not needed in two cases:

  1. The source node has been disconnected due to node shutdown (recovery is canceled as a response to cluster state processing)
  2. The current thread is the one that will be notifying the source node (happens when when of the calls from the source nodes discoveres local index is closed)

The first one is especially important as it may delay cluster state update processing with 10s.

When cancelling recoveries, we wait for up to 10s for the source node to be notified before continuing. This is not needed in two cases:
1) The source node has been disconnected due to node shutdown (recovery is canceled as a response to cluster state processing)
2) The current thread is the one that will be notifying the source node  (happens when when of the calls from the source nodes discoveres local index is closed)

The first one is especially important as it may delay cluster state update processing with 10s.
@@ -634,7 +636,8 @@ private void validateRecoveryStatus(RecoveryStatus onGoingRecovery, ShardId shar
throw new IndexShardClosedException(shardId);
}
if (onGoingRecovery.indexShard.state() == IndexShardState.CLOSED) {
cancelRecovery(onGoingRecovery.indexShard);
// mark sentCanceledToSource after cancel recovery, o.w. cancelRecovery will do nothing
Copy link
Member

Choose a reason for hiding this comment

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

comment not relevant anymore, right?

@kimchy
Copy link
Member

kimchy commented Sep 15, 2014

LGTM, minor comment

@bleskes bleskes closed this in d228606 Sep 15, 2014
bleskes added a commit that referenced this pull request Sep 15, 2014
When cancelling recoveries, we wait for up to 10s for the source node to be notified before continuing. This is not needed in two cases:
1) The source node has been disconnected due to node shutdown (recovery is canceled as a response to cluster state processing)
2) The current thread is the one that will be notifying the source node (happens when one of the calls from the source nodes discoveres the local index is closed)

The first one is especially important as it may delay cluster state update processing with 10s.

Closes #7717
bleskes added a commit that referenced this pull request Sep 15, 2014
When cancelling recoveries, we wait for up to 10s for the source node to be notified before continuing. This is not needed in two cases:
1) The source node has been disconnected due to node shutdown (recovery is canceled as a response to cluster state processing)
2) The current thread is the one that will be notifying the source node (happens when one of the calls from the source nodes discoveres the local index is closed)

The first one is especially important as it may delay cluster state update processing with 10s.

Closes #7717
@bleskes bleskes deleted the recovery_no_wait_on_cancel branch September 15, 2014 13:34
@jpountz jpountz removed the review label Oct 21, 2014
@clintongormley clintongormley added the :Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. label Jun 7, 2015
@clintongormley clintongormley changed the title Recovery: remove unneeded waits on recovery cancellation Remove unneeded waits on recovery cancellation Jun 7, 2015
mute pushed a commit to mute/elasticsearch that referenced this pull request Jul 29, 2015
When cancelling recoveries, we wait for up to 10s for the source node to be notified before continuing. This is not needed in two cases:
1) The source node has been disconnected due to node shutdown (recovery is canceled as a response to cluster state processing)
2) The current thread is the one that will be notifying the source node (happens when one of the calls from the source nodes discoveres the local index is closed)

The first one is especially important as it may delay cluster state update processing with 10s.

Closes elastic#7717
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed/Recovery Anything around constructing a new shard, either from a local or a remote source. >enhancement resiliency v1.4.0.Beta1 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants