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

Reroute eagerly on shard started events #3417

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

Comments

Projects
None yet
1 participant
@kimchy
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 in e3480a1 Jul 31, 2013

kimchy added a commit that referenced this issue Jul 31, 2013

Reroute eagerly on shard started events
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

Reroute eagerly on shard started events
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