These are chat archives for atomix/atomix
I have a few final changes I’m going to hack out:
• Simplify the cluster configuration by combining the core/bootstrap configurations. They don’t need to be separate and separating them is just confusing. The CORE nodes can just be defined in cluster/nodes.
• Adding a registry of all distributed primitives. The registry will be stored in the
system partition group and used to lookup primitive types for use in the REST API and transactions
• Support primitive configurations in the REST API and remove primitive types from REST API endpoints.
Since Atomix now has an extensible mechanism for registering primitive types, it may be better to just make the REST API itself dynamic as well. The
PrimitiveType interface can support providing an optional
PrimitiveResource or something like that that wraps a primitive instance and can be annotated with JAX-RS annotations to handle REST API calls. After that, users will be able to add new primitives that can be used via either core protocol (Raft/PB), can be configured via configuration files, and can be configured/accessed via the REST API.
Hey all! I was just looking for a bit of insight into the Copycat internals. Looking at the docs here: http://atomix.io/copycat/docs/state-machine/#implementing-state-machine-ops I was wondering how the replica state machine chooses which method to call based on a received commit? As in, how does Copycat implement:
"The generic argument to the Commit defines the operation expected by the method. Copycat will infer operation methods based on the generic argument."