Today, when executing cluster state update tasks, we have per-task hooks that can be used to execute logic after a cluster state update batch is processed. What is missing is a single per-batch hook that can be used to execute logic after a cluster state update batch is processed.
One place where this is a concern is in o.e.c.a.s.ShardStateAction where, after a batch of shard failures are processed, there is the possibility that a reroute will be required. Without the post-batch hook, this logic is placed in the post-task hook causing reroutes when needed to be executed many times.
@Override
public void clusterStateProcessed(String source, ClusterState oldState, ClusterState newState) {
if (oldState != newState && newState.getRoutingNodes().unassigned().size() > 0) {
logger.trace("unassigned shards after shard failures. scheduling a reroute.");
routingService.reroute("unassigned shards after shard failures, scheduling a reroute");
}
}
With a post-batch hook, this logic could be executed exactly once after successful publication of the new cluster state.
Today, when executing cluster state update tasks, we have per-task hooks that can be used to execute logic after a cluster state update batch is processed. What is missing is a single per-batch hook that can be used to execute logic after a cluster state update batch is processed.
One place where this is a concern is in
o.e.c.a.s.ShardStateActionwhere, after a batch of shard failures are processed, there is the possibility that a reroute will be required. Without the post-batch hook, this logic is placed in the post-task hook causing reroutes when needed to be executed many times.With a post-batch hook, this logic could be executed exactly once after successful publication of the new cluster state.