These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
123.456.789.0:5000, 123.456.789.1:5000, 123.456.789.2:5000. This is the list you pass to the
builderalong with the address of the server, which is one of the addresses in that list. This annoying tidbit is fixed in the PRs that are being merged today.
builderand local and remote hosts:ports are the second.
ClusterState: https://github.com/atomix/copycat/blob/master/server/src/main/java/io/atomix/copycat/server/state/ClusterState.java When a join request is successful (meaning the joining member's configuration is consistent with the leader's) if the joining node is not in the configuration it throws that exception. Im curious if there's something we can do to prevent this from happening aside from the already pending configuration changes.
Addresswas serialized/deserialized inconsistently. That could result in the node perceiving itself not to be present in the configuration when in fact it is.
LocalTransport(an in-memory queue) to speed them up, but I frequently run the tests with
NettyTransportto ensure everything works as expected in that context, and it seems like that should be the same environment. I'll try it again and see if anything might have changed. A gist is always helpful too :-)
DistributedGroupto support consistent hashing and facilitate partitioning schemes. Eventually, resource state machines will be abstracted from the Raft consensus algorithm, and alternative algorithms can be plugged in to manage those state machines. The initial implementation will use consistent hashing. But there are some challenges to the state machine abstraction, in particular with server-to-client communication. Copycat facilitates event driven algorithms, allowing for very efficient locking and leader election algorithms. That abstraction probably needs to be translated to any alternative replication algorithms. There are a lot of issues there in terms of consistency that have to be worked out when that's done.
DistributedGroupis that some alternative resources can be built on it. But even before that happens, users can build eventually consistent algorithms on it as well.