These are chat archives for atomix/atomix

8th
Apr 2018
Jordan Halterman
@kuujo
Apr 08 2018 07:02
Excellent
I will be in Philadelphia again this week. I’ll still be working, but may be less available during the work day (lots of meetings)
Jordan Halterman
@kuujo
Apr 08 2018 07:07
@johnou good point. The data dir is not configured correctly in the agent test. Kind of surprised that test passes
Jordan Halterman
@kuujo
Apr 08 2018 07:20

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.

Johno Crawford
@johnou
Apr 08 2018 10:05
Like the sound of the first point
So long as it's still possible to configure a cluster with defining a bunch of core nodes and have a bunch of others join as data / client
Daniel Tam
@dualscyther
Apr 08 2018 15:20

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."

using some reflection I assume, but I'm not exactly sure how I'd go about doing a similar thing. I'm writing a BFT state machine replication library and I was impressed by the Copycat API