StartedShardUpdateTask task listener #82854
Conversation
Today node removal tasks executed by the master have a separate ClusterStateTaskListener to feed back the result to the requestor. It'd be preferable to use the task itself as the listener.
idegtiarenko
added
>refactoring
:Distributed Coordination/Cluster Coordination
| @@ -872,6 +850,43 @@ public int hashCode() { | |||
| } | |||
| } | |||
|
|
|||
| public static class StartedShardUpdateTask implements ClusterStateTaskListener { | |||
There was a problem hiding this comment.
This change is similar to #82795,
though I wonder if it make sense to gentrify this class for both Started and Failed entry.
This will result in less code, however some of the declarations might get longer
There was a problem hiding this comment.
s/gentrify/generify/?
I'm not sure there's much to be gained from extracting a common base class for the two requests at the moment. It wouldn't reduce any code duplication AFAIK. I think it makes more sense to aim for splitting ShardStateAction into separate action classes for the shard-started and shard-failed functionality since they're conceptually quite independent. The sendShardAction method is not really doing anything that TransportMasterNodeAction couldn't do today, although I would like to change the behaviour here so that when a new master is elected we send all the retries in a single transport request.
|
Pinging @elastic/es-distributed (Team:Distributed) |
Today node removal tasks executed by the master have a separate
ClusterStateTaskListener to feed back the result to the requestor.
It'd be preferable to use the task itself as the listener.
Rel: #82644