These are chat archives for atomix/atomix
Atomixinterface exposes two methods for creating resource instances:
create. Both methods essentially perform a create-if-not-exists type operation to create the resource in the cluster if it doesn't already exist. The difference between
createis actually in the number of instances that can be created per node. The term "instance" refers to an instance of an object in the typical sense. An instance of a distributed resource is an object in a single JVM. The
getmethod is essentially a per-node singleton method. When a client or replica calls
get, it creates the resource in the cluster if it doesn't already exist, and if an instance of the resource has already been referenced by the client/replica then that singleton instance will be returned, otherwise one will be created and cached. Alternatively, the
createmethod allows a single node to create multiple logical instances of a resource. Each time the
createmethod is called, the resource will be created in the cluster of it doesn't exist, and a new Java object will be returned.
getis to allow multiple threads to create and reference the same resource without having to coordinate with each other. It essentially says, get or create an instance of the resource, whereas
createsays create a new instance of the resource (though the resource's state machine may already exist)
foolock and for each instance of the lock to behave independently of the other lock instances on the node. In a multithreaded environment this means one thread can acquire the distributed lock without all threads acquiring it, and each thread can acquire the lock independently of the other threads.
createmultiple instances of a queue and consume queued messages independently of one another.
get, a state machine for that resource is created on each server. When a client/replica calls
getfor the first time or calls
create, a new logical session is created to allow the replicated state machine to send messages to that specific object. Logical sessions all share the same real underlying session, and so a million distributed objects on a single node would still only require a single keep-alive for the session.
DistributedMessageBusare treated as state changes. So, all messages published to a
DistributedTopicare replicated through the Raft algorithm. The long term goal of Atomix is to make this behavior configurable. Resources should support different replication/consistency levels to allow them to be configured for performance and fault tolerance. All current resources aside from
DistributedMessageBusprovide strong consistency. Ideally, in the future a
DistributedTaskQueueshould handle only state changes (adding/removing consumers and handling failures) through the Raft algorithm and support configurable behaviors like dispatch and replication factor. I could probably prototype something like this, but it's really outside the scope of the 1.0 release.