[
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)
