These are chat archives for atomix/atomix
EPHEMERAL. This is looking at cluster management as independent from storage/replication. The requirements of Raft are that the membership not dynamically evolve, so we just need node types that meet those requirements.
PERSISTENTnodes would always exist in the configuration whether dead or alive until removed, and
EPHEMERALnodes are either alive or not members of the cluster.
Also would like to decouple the system partition from the node types as well and perhaps allow a system partition/group to be provided.
With that done, I also think it could be useful to have some sort of abstraction that provides common configurations. My concern is that the decoupling of the protocols from primitives makes it more complicated to configure Atomix and its primitives, and it would be nice to have a high level abstraction that provides e.g. an enum or something for common configurations (i.e. a configuration for large scale data, for f+1 fault tolerance, for strong consistency/coordination, etc and consistency/persistence/performance based configurations for primitives).
Unknown partition group type: multi-primary io.atomix.utils.ConfigurationException: Unknown partition group type: multi-primary. Have not found answer in currently cut "getting started section" on website.
PartitionGroups.getPrimaryBackupGroupFactory().createSystemGroup(3,dataDirectorypath)is almost the same ?
EPHEMERAL, The latter makes me think more about the storage persistance rather than cluster membership, so from that perspective, I like
EPHEMERALpartly because that is how they behave in terms of state as well
DistributedLockwill be granted to the longest waiting process, but we don’t currently have a read/write lock. I always thought that would be cool to have. Just need to add a new primitive for it.
CLIENTnodes as well.
CLIENTas it’s simpler to understand, though. Clients are really a special type of
EPHEMERALnode that can’t be assigned partitions.