[
https://issues.apache.org/jira/browse/IGNITE-18639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18639:
-------------------------------------
Description:
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 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.
was:
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.
> 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}
> 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 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)
