These are chat archives for atomix/atomix

29th
Mar 2018
Jordan Halterman
@kuujo
Mar 29 2018 05:36
yes I missed that
Nobin Mathew
@nmathew
Mar 29 2018 06:27
I hope I am not posting wrong question to this forum,
whether atomix uses catalyst anymore, or there are entirely different projects?
Jordan Halterman
@kuujo
Mar 29 2018 06:33
no wrong questions here

Catalyst is now defunct. The portions of it that were kept are now in Atomix (mostly the buffers) and everything else has been replaced or rewritten.

Serialization was replaced with Kryo, and new messaging APIs for the Atomix use case were created.

Jordan Halterman
@kuujo
Mar 29 2018 06:38
Everything Atomix uses that’s not called Netty or Kryo has been consolidated in the Atomix project itself
Nobin Mathew
@nmathew
Mar 29 2018 06:41
Thanks Jordan
Jordan Halterman
@kuujo
Mar 29 2018 07:13

Let there be multicast!

Wasn’t too hard to hack together. Seems to work alright. But I suspect the slight rearchitecting of nodes is going to take a little time to settle down.

So, here’s the new architecture:
CORE nodes can store Raft partitions and must be explicitly configured on all other CORE nodes
DATA nodes can store primary-backup partitions and don’t have to be configured, but if CORE nodes exist they do have to know about them at startup
• Same goes for CLIENT nodes, which don’t store any data
DATA nodes can run independently of CORE nodes
DATA and CLIENT nodes can discover each other through multicast or IPs

It should also be feasible to allow data and client nodes to discover partition groups as well, that way they don’t have to know about the core nodes either. Then, only the core nodes have to know about the core nodes, and data/client nodes can use multicast or IPs to find each other and the core nodes.

Jordan Halterman
@kuujo
Mar 29 2018 07:56
I think we should get the member groups change merged and then clean this up and use it and a second PR to handle partition group discovery to add a lot of tests for cluster membership
Johno Crawford
@johnou
Mar 29 2018 12:10
@kuujo I'll try and get to the reviews soon, problems at work
Jon Hall
@jhall11
Mar 29 2018 19:07
So could you start a node as DATA, with only one known ip for a cluster, have it get in sync, then transition to a CORE?
Jordan Halterman
@kuujo
Mar 29 2018 19:30
@jhall11 DATA nodes are prone to network partitions, so that would risk split brain if e.g. two data nodes only see themselves and then switch to CORE. The core nodes always have to be explicitly listed for that reason.
Jon Hall
@jhall11
Mar 29 2018 19:31
ah, that makes sense
Jordan Halterman
@kuujo
Mar 29 2018 19:33
There is a pattern that is safe though: using a single configuration node that can decide which nodes form the CORE cluster. A single node can’t suffer from a network partition, but if it crashes then your cluster can’t be reconfigured. But this is what Kubernetes has done successfully
Jon Hall
@jhall11
Mar 29 2018 19:36
ok, that should work pretty well, i guess if your cluster needs constant reconfiguring, it may be an issue, but as long as the node is generally available, you shouldn’t have much issues