These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
MemberState::canAppendshould never return
appending == 0
LINEARIZABLEquery needs to perform a quick heartbeat to ascertain quorum. But the corresponding
AppendRequestcannot be sent out because
false. This leaves
heartbeatFutureas non-null and subsequent heartbeat’s get queued up. Only way to exit this impasse if is if a new entry is appended to the log (A keep-alive will do) and replicated. But if the followers timeout on leader heartbeat before that happens, they will start a new poll and one of them will take over leadership.
AtomixReplicaand the standalone server are all completely interchangeable. A cluster just has to have at least one replica or server, and clients can operate on that state. A replica is literally just a client/server combined. When you're working with a replica you're actually just using a client that passes requests directly to the underlying server. To modify the state of a replica from a client, just create a
DistributedValueand do you're thing. All instances of the
DistributedValuewith the same name point to the same state in the cluster. So,
"foo"created on a replica is the same distributed object as
"foo"created on a client. They're both backed by the same replicated state machine.
appending == 0 ||to
MemberState::canAppendshould fix it?
thenRun. If you use
whenCompleteit will probably be called with a non-null error perhaps due to serialization or something like that.