These are chat archives for atomix/atomix
Clustermethods directly could mess up the replica. So, it depends on what we need to expose and why, and maybe we can do it.
I’ve accessed the cluster thro reflection
Gotta do what you gotta do :-P
Another concern is bootstrapping and restarting agents - as i understand atomix persist cluster state and reuse it after restart? So i need bootstrap and join only at initialization time? Could i get persisted cluster state at the agent start? How can i deregister dead replica in cluster?
This is correct if you’re using
StorageLevel.MAPPED. The cluster configuration is stored on each node in the
.metadata file. You can actually read it directly from the
Storage storage = Storage.builder(StorageLevel.DISK)…build(); MetaStore metaStore = storage.openMetaStore(serverName); MetaStore.Configuration configuration = metaStore.loadConfiguration();
But the proper way to access it would be through the Copycat
Cluster accessible via
Cluster object is actually initialized when the server is created as opposed to when it’s started, so I think you should be able to read the configuration prior to calling
join via the server’s
Regardless of the fact that the configuration is persisted, though, you still need to call either
join to recover a failed node, the method is just idempotent. If a server is always started via
bootstrap, it will only ever actually bootstrap the cluster if there is no persisted configuration. Subsequent calls to
bootstrap will just cause the server to start. Whether this consistency makes it easier or more difficult to use depends on how people use it.
You can also remove a failed node from the cluster via the
Similarly, you can
demote() a member remotely. The way this is done in Atomix is by using the
Clusters leader election and calling
demote only from the leader. Internally, Copycat will ensure that changes to the cluster configuration can only be made by a node that has an up-to-date configuration, so if you use the leader election API to make changes from the leader it will be done safely. Even if two leaders exist and the older leader attempts to remove another node from the cluster, that operation will fail since it has been superseded by a newer leader.
DistributedLockthere is still an effective timeout and thus a liveness guarantee based on session timeouts. If a client’s session expires after acquiring a lock, the lock will be released. So, effectively the session expiration mechanism behaves like a lease on the lock that’s renewed each time the client sends a keep-alive to the cluster.
close(ServerSession)on the state machine when a client’s session is unregistered or is expired by the leader, and the lock state machine releases the lock if it’s associated with that session: https://github.com/atomix/atomix/blob/master/concurrent/src/main/java/io/atomix/concurrent/internal/LockState.java#L42-L59
withSessionTimeoutis the method you want
.5 * sessionTimeout