Comment on the extra reroute after failing shards (#44152)

The `ShardFailedClusterStateTaskExecutor` fails some shards, which performs a
reroute, but then sometimes schedules a followup reroute. It's not clear from
the code why this followup is necessary, so this commit adds a short comment
describing why it's necessary.
This commit is contained in:
David Turner 2019-07-10 13:23:40 +01:00
parent cad804df92
commit d0f1a756d9
1 changed files with 5 additions and 4 deletions

View File

@ -378,10 +378,11 @@ public class ShardStateAction {
public void clusterStatePublished(ClusterChangedEvent clusterChangedEvent) { public void clusterStatePublished(ClusterChangedEvent clusterChangedEvent) {
int numberOfUnassignedShards = clusterChangedEvent.state().getRoutingNodes().unassigned().size(); int numberOfUnassignedShards = clusterChangedEvent.state().getRoutingNodes().unassigned().size();
if (numberOfUnassignedShards > 0) { if (numberOfUnassignedShards > 0) {
String reason = String.format(Locale.ROOT, "[%d] unassigned shards after failing shards", numberOfUnassignedShards); // The reroute called after failing some shards will not assign any shard back to the node on which it failed. If there were
if (logger.isTraceEnabled()) { // no other options for a failed shard then it is left unassigned. However, absent other options it's better to try and
logger.trace("{}, scheduling a reroute", reason); // assign it again, even if that means putting it back on the node on which it previously failed:
} final String reason = String.format(Locale.ROOT, "[%d] unassigned shards after failing shards", numberOfUnassignedShards);
logger.trace("{}, scheduling a reroute", reason);
rerouteService.reroute(reason, ActionListener.wrap( rerouteService.reroute(reason, ActionListener.wrap(
r -> logger.trace("{}, reroute completed", reason), r -> logger.trace("{}, reroute completed", reason),
e -> logger.debug(new ParameterizedMessage("{}, reroute failed", reason), e))); e -> logger.debug(new ParameterizedMessage("{}, reroute failed", reason), e)));