Skip shard management code when updating cluster state on client/tribe nodes#20731
Merged
ywelsch merged 1 commit intoelastic:masterfrom Oct 4, 2016
Conversation
bleskes
approved these changes
Oct 4, 2016
Contributor
bleskes
left a comment
There was a problem hiding this comment.
Good change. Left some very minor comments. +1 to push it everywhere.
Contributor
There was a problem hiding this comment.
nit: I prefer the following check:
if(clusterService.localNode().isDataNode() || clusterService.localNode().isMasterNode()) {
clusterService.addFirst(this);
}
Contributor
Author
There was a problem hiding this comment.
ClusterService has not been started at that point and clusterService.localNode() throws an java.lang.IllegalStateException when invoked here. We might do some reordering in the initialization logic etc. but as this commit targets multiple versions I wanted the change to be simple.
Contributor
There was a problem hiding this comment.
I dont' think we need master nodes here?
Contributor
Author
There was a problem hiding this comment.
agree, I'll enable it only for data nodes.
…e nodes IndicesClusterStateService and IndicesStore are responsible for synchronizing local shard state based on incoming cluster state updates. Cluster state updates trigger shard initializations, starting recoveries or deleting shard and index data / metadata. On client/tribe nodes, which don't store any shard/index data/metadata, all of this is unnecessary, wasting precious CPU cycles.
23afd25 to
abc35cd
Compare
Contributor
Author
|
Thanks @bleskes! |
ywelsch
added a commit
that referenced
this pull request
Oct 4, 2016
…e nodes (#20731) IndicesClusterStateService and IndicesStore are responsible for synchronizing local shard state based on incoming cluster state updates. On client/tribe nodes, which don't store any such shard/index data/metadata, all of the logic that computes which data is to be deleted, which shards to be initialized etc. can be completely skipped, saving precious CPU cycles.
ywelsch
added a commit
that referenced
this pull request
Oct 4, 2016
…e nodes (#20731) IndicesClusterStateService and IndicesStore are responsible for synchronizing local shard state based on incoming cluster state updates. On client/tribe nodes, which don't store any such shard/index data/metadata, all of the logic that computes which data is to be deleted, which shards to be initialized etc. can be completely skipped, saving precious CPU cycles.
ywelsch
added a commit
that referenced
this pull request
Oct 4, 2016
…e nodes (#20731) IndicesClusterStateService and IndicesStore are responsible for synchronizing local shard state based on incoming cluster state updates. On client/tribe nodes, which don't store any such shard/index data/metadata, all of the logic that computes which data is to be deleted, which shards to be initialized etc. can be completely skipped, saving precious CPU cycles.
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.
IndicesClusterStateServiceandIndicesStoreare responsible for synchronizing local shard state based on incoming cluster state updates. Actions that are taking are initializing shards, starting recoveries, or deleting shard and index data. On client or tribe nodes, which don't store any shard/index data, all of this is unnecessary, wasting unnecessary cycles to apply cluster state updates.