These are chat archives for atomix/atomix

Mar 2017
Mar 21 2017 14:35
@electrical thanks but note that DistributedGroup members are not necessarily part of raft cluster and could just be clients, you are probably talking about the raft cluster leader election. however, leader election in atomix DistributedGroup works via GroupState state machine that keeps a list of all members in a candidates list and selects a new leader from lists if old leader member's session expires ..... if current leader member (node A) is partitioned off then its session becomes UNSTABLE and keeps on trying to reconnect to the copycat cluster (or the RAFT cluster) .... its session is expired by copycat cluster and a new member is elected leader (with a newer term) but node-A continues to believe that it is the leader of DistributedGroup. that is my understanding and it could be wrong of course, hence I posted the question :)
In my case though, I am writing my own DistributedGroup implementation as that simplifies things for me. So while understanding atomix DistributedGroup I realized the catch of the leader election there. In my implementation, I am probably gonna make a member stop doing leader activities as soon as its copycat client state reaches SUSPENDED. (note that I'm talking about leadership in the context of my group and not leader of the raft cluster)