These are chat archives for atomix/atomix

Jan 2017
Jordan Halterman
Jan 27 2017 06:28 UTC
Thanks again for the input. It’s really helpful to know how people are using these projects. I don’t expect any programmatic APIs to change significantly, and new features will be added as separate extensions wherever possible.
I expect to start work on the HTTP API tonight and figure out answers to all these questions through the weekend.
Jan 27 2017 14:14 UTC
Hello, have started to experiment with Atomix. Excellent API ! I have a small question: When a leader leaves, does the onElection gets triggered first , or onLeave event. And any reason why it is one way or the other ? Or it doesnt have any sequential guarantee ?
Gordon Tillman
Jan 27 2017 18:36 UTC
Greeting all. Just working through the getting started guide. Using cc-server/client 1.2.0 and catalyst-netty 1.1.2. Getting the following exception which I attempt to execute a PutCommand: io.atomix.catalyst.serializer.SerializationException: cannot serialize unregistered type: class io.atomix.copycat.server.state.ServerCommit. Any thoughts?
Jordan Halterman
Jan 27 2017 19:00 UTC
When a leader leaves the group, the onLeave event will occur first, then the term will be incremented and the leader will be reset, then the leader will be set and the onElection event 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.
Jon Hall
Jan 27 2017 19:01 UTC
How do you envision support for 1.0 vs. 2.0. It sounds like 2.0 is “backwards compatible” in terms of api, so upgrading should be easy. But do you expect there to be further releases for the 1.0 branch?
Jordan Halterman
Jan 27 2017 20:09 UTC
So, for the most part 2.0 will be backwards compatible as far as user-facing APIs are concerned. AtomixClient and AtomixReplica won’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.