These are chat archives for atomix/atomix

25th
Jan 2017
Jordan Halterman
@kuujo
Jan 25 2017 00:17

Copycat/Atomix 2.0

Copycat 2.0 and Atomix 2.0 are currently under development. I'd like to invite anyone with ideas on what they'd like to see in the projects to contribute to the discussion.

The development that is currently underway focuses on usability, portability, and performance:

  • The biggest new feature is HTTP support. Copycat will support a REST protocol and a state machine extension that allows commands/queries to be defined by JAX-RS annotations. Atomix will use JAX-RS to make resources available via a REST API. This will hopefully significantly simplify Atomix and the implementation of Atomix resources.
  • Copycat will support a web socket/JSON/BSON protocol alongside the HTTP protocol to simplify the implementation of client's in other languages.
  • But HTTP/web sockets will not be the only API. The Java client will still use the native binary protocol which Copycat uses internally for replication.
  • The Copycat log is being completely rewritten to support a single writer and multiple readers. Previously, the Copycat server was largely single threaded aside from transports and state management. That will still necessarily be the case on the write path, but supporting multiple reader will allow leaders to replicate to followers in parallel. The rewrite will also eliminate the need for indexing in the Copycat log and significantly reduce the memory footprint and overhead of reading from the log.
  • Catalyst will be replaced by packages inside of Copycat. For serialization, Kryo and Jackson will be used for performance.

I'm open to other ideas from users.

Chris Cleveland
@ccleve
Jan 25 2017 17:34
JAX-RS is good, but Jersey, Resteasy and the other libraries carry a lot of overhead. I like the fact that Copycat relies only on a lightweight Netty server inside. What JAX-RS library do you plan to use?
Jordan Halterman
@kuujo
Jan 25 2017 19:09

Good question @ccleve

So, we're certainly not going to add any additional overhead to Copycat/Atomix. I'm only interested in the JAX-RS annotations insofar as they're a widely used, well documented, well understood API. Ultimately, using JAX-RS annotations is just a nice way to specify a REST API for a state machine. In practice, the state machine isn't actually itself a REST server since Copycat has to handle and replicate changes before they're applied.

So, really how it's structured is: the Copycat server can be configured with an HttpProtocol. When the HttpProtocol is used, a basic Netty HTTP API is set up for managing sessions and things like that. All requests that don't relate to session management are intercepted by the HTTP and converted into HTTP commands and queries (HttpQuery for GET requests and HttpCommand for everything else). From that point, the HTTP operations are handled like normal operations, logged and replicated if necessary. Once they're committed and applied to the state machine, HttpCommand and HttpQuery are specially handled in the state machine using the JAX-RS annotations. So, really this is just a nice way to specify an HTTP API for a Copycat state machine without actually using any of the existing implementations of the JAX-RS spec. Copycat is essentially it's own implementation of the spec.

I'm still not sure I'm sold on using JAX-RS annotations though. The alternative is a code-based configuration of an API or implementing some annotations specific to Copycat's HTTP support. I think the final direction will depend on how clean this approach feels when I get to it this weekend. Handling HTTP requests in the state machine will be the last major phase of refactoring.

But having built proofs of concept for all the other features already, I expect it to work out actually a bit better than I thought it would.