Master should wait on cluster state publication when failing a shard#15468
Merged
jasontedor merged 1 commit intoelastic:masterfrom Dec 16, 2015
jasontedor:master-side-of-wait-on-shard-failures
Merged
Master should wait on cluster state publication when failing a shard#15468jasontedor merged 1 commit intoelastic:masterfrom jasontedor:master-side-of-wait-on-shard-failures
jasontedor merged 1 commit intoelastic:masterfrom
jasontedor:master-side-of-wait-on-shard-failures
Conversation
Contributor
There was a problem hiding this comment.
this keeps bugging me :) we should something on the executor as well....
Member
Author
There was a problem hiding this comment.
We discussed this through another channel; the issue is the possible reroutes are being issued for every task rather than once per batch. Modifying this behavior will require a little extra machinery in the cluster state task execution framework. I opened #15482 to address.
Contributor
|
LGTM |
When a client sends a request to fail a shard to the master, the current behavior is that the master will submit the cluster state update task and then immediately send a successful response back to the client; additionally, if there are any failures while processing the cluster state update task to fail the shard, then the client will never be notified of these failures. This commit modifies the master behavior when handling requests to fail a shard. In particular, the master will now wait until successful publication of the cluster state update before notifying the request client that the shard is marked as failed; additionally, the client is now notified of any failures during the execution of the cluster state update task. Relates #14252
jasontedor
added a commit
that referenced
this pull request
Dec 16, 2015
…d-failures Master should wait on cluster state publication when failing a shard
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a client sends a request to fail a shard to the master, the current
behavior is that the master will submit the cluster state update task
and then immediately send a successful response back to the client;
additionally, if there are any failures while processing the cluster
state update task to fail the shard, then the client will never be
notified of these failures.
This commit modifies the master behavior when handling requests to fail
a shard. In particular, the master will now wait until successful
publication of the cluster state update before notifying the request
client that the shard is marked as failed; additionally, the client is
now notified of any failures during the execution of the cluster state
update task.
Relates #14252