[
https://issues.apache.org/jira/browse/IGNITE-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-18639:
-----------------------------------------
Labels: iep-101 ignite-3 (was: ignite-3)
> 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: iep-101, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 50m
> 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)
