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