These are chat archives for atomix/atomix

Jul 2016
Jul 20 2016 10:14
Hello! I'm new to Atomix, and I'm considering it to replace ZooKeeper in a research project.
So this is my raw, naive feedback as new user and some related questions.
a) issues in getting started w/ standalone server -- can't start the shaded jar downloaded from Maven as in the doc: it goes NullPointerExc because of a missing, and when I feed it the conf file from the repo it complains ("no default serializer found for type: class io.atomix.copycat.protocol.QueryRequest"). So I downloaded the source and started the standalone server from there ("java -jar target/atomix-standalone-server.jar -address -bootstrap"): it works
b) issues with connecting the client -- for some reason the code of the client example hangs and never gets to print "Client connected!"... there must be something trivial that blocks the client. Still, hanging like this is not nice...
c) is dvariable.onStateChange() similar to ZooKeeper watches?
Thanks, also for the hard work of putting all this together: it looks very promising
Jordan Halterman
Jul 20 2016 17:04
Thanks! I realized there are some issues with the standalone server configuration. I'll have to check on the examples. Lastly...
Jordan Halterman
Jul 20 2016 17:10
The onStateChange method is almost identical to how state changes occur in ZooKeeper clients. The state change is really just an indicator of the health of the client's session and its ability to communicate with servers. But Copycat/Atomix does have something very similar to ZooKeeper's watches but with a few more guarantees. Atomix is made up of a bunch of Copycat state machines. Copycat state machines and clients have an abstraction similar to watches called session events. Session events can be used by the state machine to send any kind of notification to a client. For example, in the case of DistributedGroup, the state machine sends an event whenever a member joins the group or a leader change occurs. ZooKeeper's watches are sort of low level primitives on which patterns can be built. But session events are a more customizable version of watches that help build higher level notifications for specific state machines and specific use cases. They work in almost exactly the same way as watches. The server to which the client is connected sends the event to the client, and events are guaranteed to be received in sequential order. But they have stronger guarantees in that Copycat replicates session events, so if a client switches servers and misses an event, the server to which the client connects will have the event and will re-send it to the client. Furthermore, clients don't typically need to reregister after receiving an event, though that's really up to the state machine implementation.
I think the standalone server just needs to be built with a script and default configuration
Roman Pearah
Jul 20 2016 23:00
@pviotti If you're familiar with docker, check out my repo for a standalone replica