[jira] [Updated] (IGNITE-18639) Implement distributed onLeaderElected callback within topology aware raft client

["Alexander Lapin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin updated IGNITE-18639:
-------------------------------------
    Summary: Implement distributed onLeaderElected callback within topology aware raft client  (was: Implement topology aware raft client with new awaitLeader() method)

> Implement distributed onLeaderElected callback within topology aware raft client
> --------------------------------------------------------------------------------
>
>                 Key: IGNITE-18639
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18639
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>              Labels: ignite-3
>
> h3. Motivation
> As a prerequisite for 
>  * Reactive raft client.
>  * Possible in-group rebalance leader change detection.
>  * Replication group readiness checks.
> it's requited to implement new raft client (additional one, but not the substitution of existing RaftGroupService) that will have new
> {code:java}
> CompletableFuture<Peer> awaitLeader(){code}
>  method. This method returns a future that will be completed with new leader's peer when the new leader is elected. Given method should work in a distributed manner unlike the local  RaftGroupEventsListener#onLeaderElected callback.
> ! By the way, I'm not sure whether we need awaitLeader() method or distributed onLeaderElected callback itself. Anyway it's potato- potahto because the internals will be almost the same. We can decide which is better during the implementation.
>  
> h3. Definition of Done
>  * new TopologyAwareRaftGroupService is introduced with new distributed awaitLeader() method.
> h3. Implementation Notes
> The core idea that new raft client sends awaitLeaderMsg with corresponding raft group id to all peers that register a future on the raft server that will be completed when local on leader elected is fired, so yes, we should reuse local RaftGroupEventsListener#onLeaderElected. Within given callback raft server send awaitLeaderResponse with new leader as a peer.
> Let's check following example, assuming that we have raft group G1 with peers (A, B, C) and a raft client on node D.
> RaftClient(D) -> awaitLeaderMsg -> RaftServer (A) -> onLeaderElected(()-> awaitLeaderRespMsg(A))
>                            -> awaitLeaderMsg -> RaftServer (B) -> onLeaderElected(()-> awaitLeaderRespMsg(B))
>                             -> awaitLeaderMsg -> RaftServer (C) -> onLeaderElected(()-> awaitLeaderRespMsg(C))
>  
> onLeaderElected, because of its local nature, will be fired on one node only (and if the leader will be reelected another onLeaderElected will be triggered) and this node will send the response to the client.
>  
> Nontrivial issue here is that  some peers may be unavailable during awaitLeader call, so there won't be server side actor that will register onLeaderElected that's why new raftService is topology aware. on awaitLeader call it registers a listener on node appearance though the corresponding topology service(we should do our best to support both network and logical typologies here) and on apper send awaitLeaderMsg so that we won't skip leader appearance on previously unavailable node. Of course besides topology listeners we should send corresponding awaitLeaderMsg to the peers that are already present in the topology.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)