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

["Vyacheslav Koptilin (Jira)" <ji...@apache.org>]

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

Vyacheslav Koptilin updated IGNITE-18639:
-----------------------------------------
    Reviewer: Denis Chudov

> 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
>            Assignee: Vladislav Pyatkov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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}
> onLeaderElected(Peer newLeader, long term){code}
>  callback that should work in a distributed manner unlike the local  RaftGroupEventsListener#onLeaderElected callback.
> h3. Definition of Done
>  * new TopologyAwareRaftGroupService is introduced with new distributed onLeaderElected() callback.
> h3. Implementation Notes
> The core idea that new raft client sends onLeaderElectedMsg 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 onLeaderElectedResp with new leader as a peer and term for linearization purposes.
> 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) {-}> onLeaderElectedMsg -> RaftServer (A) -> onLeaderElected((){-}> onLeaderElectedMsgResp(A))
>                            {-}> onLeaderElectedMsg -> RaftServer (B) -> onLeaderElected((){-}> onLeaderElectedResp(B))
>                             {-}> onLeaderElectedMsg -> RaftServer (C) -> onLeaderElected((){-}> onLeaderElectedResp(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 calback registraion, so there won't be server side actor that will register onLeaderElected that's why new raftService is topology aware. on onLeaderElected 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 appear send onLeaderElectedMsg so that we won't skip leader appearance on previously unavailable node. Of course besides topology listeners we should send corresponding onLeaderElectedMsg to the peers that are already present in the topology.
>  
>  



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