These are chat archives for atomix/atomix

27th
Jan 2017
Jordan Halterman
@kuujo
Jan 27 2017 06:28
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.
srirohit
@srirohit
Jan 27 2017 14:14
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
@gordyt
Jan 27 2017 18:36
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
@kuujo
Jan 27 2017 19:00
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
@jhall11
Jan 27 2017 19:01
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
@kuujo
Jan 27 2017 20:09
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.