These are chat archives for atomix/atomix

Mar 2017
Kevin Daly
Mar 20 2017 15:06
So I'm having some issues shutting down an Atomix cluster.. The last node get's hung up with this message
[.2:8700-copycat] i.a.c.transport.netty.NettyClient : Connecting to meta-config-2/
the node it is trying to contact was shut down with
((AtomixReplica) atomix).leave().get(2, TimeUnit.MINUTES);
Mar 20 2017 20:50
some questions... thanks
(1) CopycatClient is bootstrapped with a list of Addresses. Is it possible to reset the bootstrap addresses on same copycat client object after it went to suspended/closed state?
(2) When using MEMORY storage level, does MetaStore also use MEMORY buffer and <term, vote> is written only in memory? If yes, then isn't it going to be problematic if a server crashes and restarted very quickly while raft leader election was happening... node would forget that it already voted for the term and might give its vote again to some other candidate in same term. no?
(3) For MEMORY storage level, it seems jvm heap memory is used... in this case I can't see the benefit of jvm managing that memory ... wouldn't it be better to use off-heap memory so that GC is not impacted by copycat's buffers?
(4) Atomix DistributedGroup leader election, it appears if a node becomes group leader and then it's AtomixClient goes to SUSPENDED state (for whatever reason, say this particular node is partitioned off). Then this node will continue to think it is the group leader but rest of the nodes in group get a new leader elected. no?
Richard Pijnenburg
Mar 20 2017 22:28
@himanshug i cant comment on most things because my knowledge about atomix doesn't go that deep. but regards any leader actions and also i believe the one you describe in your 4th question. it will require a majority of nodes to agree on who's the leader. If most nodes agree that node b is the leader but node a believes was the leader, that node will resign the leadership and try the join action and then will most likely join the new leader.