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
io.atomix.catalyst.serializer.SerializationException: cannot serialize unregistered type: class io.atomix.copycat.server.state.ServerCommit. Any thoughts?
onLeaveevent will occur first, then the term will be incremented and the leader will be reset, then the leader will be set and the
onElectionevent will fire for a new leader. There are strong sequential guarantees in Atomix. All clients with active sessions are guaranteed to see these these events in this order. And they'll all be sent to the client in a single batch and will occur in sequence with no responses or anything interleaved with them. The rationale behind the order is simply that it mimics the order of most election algorithms. A node crashes, then an epoch is increased and a new leader is elected.
AtomixReplicawon’t change. The changes are all internal and transparent from most users’ perspectives. Copycat/Atomix 1.x will continue to be maintained and released as a lot of the most important work - in resource state machines - will still be in Atomix 2.0, and I want any bugs to be fixed and brought into 2.0. I have no real timeline for deprecating that work.