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

Jump to bottom

Reroute eagerly on shard started events #3417

Closed
kimchy opened this issue Jul 31, 2013 · 0 comments
Closed

Reroute eagerly on shard started events #3417

kimchy opened this issue Jul 31, 2013 · 0 comments
Labels
>enhancement v0.90.3 v1.0.0.Beta1

Comments

@kimchy
Copy link
Member

kimchy commented Jul 31, 2013

We have an optimization where we try to delay reroute after we processed the shard started events to try and combine a few into the same event. With teh queueing of shard started events in places, we don't need to do it, and we can reroute right away, which will actually reduce the amount of cluster state events we send.

This will also have a nice side effect of not missing on "waitForRelocatingShards(0)" on cluster health checks since relocations will happen right away.
@kimchy kimchy closed this as completed in e3480a1 Jul 31, 2013
kimchy added a commit that referenced this issue Jul 31, 2013
@kimchy
Reroute eagerly on shard started events
db0a5f0 
We have an optimization where we try to delay reroute after we processed the shard started events to try and combine a few into the same event. With teh queueing of shard started events in places, we don't need to do it, and we can reroute right away, which will actually reduce the amount of cluster state events we send.

This will also have a nice side effect of not missing on "waitForRelocatingShards(0)" on cluster health checks since relocations will happen right away.

closes #3417
mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015
@kimchy
Reroute eagerly on shard started events
ed97918 
We have an optimization where we try to delay reroute after we processed the shard started events to try and combine a few into the same event. With teh queueing of shard started events in places, we don't need to do it, and we can reroute right away, which will actually reduce the amount of cluster state events we send.

This will also have a nice side effect of not missing on "waitForRelocatingShards(0)" on cluster health checks since relocations will happen right away.

closes elastic#3417
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
>enhancement v0.90.3 v1.0.0.Beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@kimchy