Alexander Lapin created IGNITE-18639:
----------------------------------------
Summary: Implement topology aware raft client with new
awaitLeader() method
Key: IGNITE-18639
URL: https://issues.apache.org/jira/browse/IGNITE-18639
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
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)
