These are chat archives for atomix/atomix

11th
Jun 2016
Jordan Halterman
@kuujo
Jun 11 2016 01:32
@madjam thanks I'll check it out tonight
Jordan Halterman
@kuujo
Jun 11 2016 01:46
@jamiethermo this is done in Atomix in AtpmixReplica which you can use as an example. This is the way I'd recommend more or less embedding the server. Otherwise, as @jhalterman said the protocol for interacting with state machines is really deeply embedded in Copycat and is already built in to clients. The way it's done in AtomixReplica is by using the LocalTransport which just uses queues rather than networks. Configure the servers with a serverTransport that uses NettyTransport and a clientTransport that uses LocalTransport, then configure a client with the same LocalTransport instance. This is why that abstraction exists.
You can also set the session timeout to something really large to reduce the overhead of sessions. Keep alives are sent by clients at a rate of half the session timeout. Theoretically, you could set it to an hour or something to make sure old/dead sessions are still cleared from the log as long as the state machine is not relying on session state change events.
Jordan Halterman
@kuujo
Jun 11 2016 01:54
The serverTransport is the Transport servers use to communicate with each other, which presumably still needs to be a network, and the clientTransport is the Transport clients use to communicate with servers, which can be LocalTransport if no client needs to connect remotely. This is how I would build a REST API on top of Copycat. Then if you don't need to use sessions then the overhead of sessions is limited to the number of nodes in the cluster. If you do need to use sessions them create a separate CopycatClient per session.
Copycat will handle proxying requests sent over the clientTransport to the leader via the serverTransport when necessary
Jordan Halterman
@kuujo
Jun 11 2016 02:14
There's not really any reason disabling sessions would be difficult. But you have to realize that some of the ordering guarantees handled in sessions dont necessarily imply loss of performance. The ordering guarantees allow e.g. sequential consistency when reading from followers, which is a weaker consistency level and much more efficient than reading from leaders. But without sessions, it would not be possible to do so safely without the client seeing state go back in time when switching servers. Sessions are still relevant even when using LocalTransport on a server since servers may still proxy sequential reads to another node if the local node is too far behind the leader or is partitioned from the leader.
Hmm this made me realize followers should perhaps be rejecting reads after an election timeout. I'm not sure that would happen now because the pre-vote protocol could prevent a partitioned follower from ever incrementing its term and resetting the leader state
Jordan Halterman
@kuujo
Jun 11 2016 06:07
@andreas-gilbert AtomixClient technically only needs one server to connect to. But the availability of your cluster is dependent on the number of nodes. Two or fewer nodes doesn’t allow any nodes to fail, meaning if a node fails the system will stop working. It will work perfectly fine with one or two nodes, but only if those one or two nodes are available at all times.
@madjam I think I see the bug… should be an easy fix
jamiethermo
@jamiethermo
Jun 11 2016 22:22
@kuujo Thanks!