Accept proposes a value into a log index position.
Accept proposes a value into a log index position. Followers must:
1. Nack if a promise has been made to a Prepare request with a higher BallotNumber. 1. Request retransmission of lost messages if the logIndex leads to a gap in log index sequence. 1. If the Ack with a positive response then journal the accept message at the log index if the number is higher than the message currently store at this index.
Unique identifier for this request.
The value to accept at the slot position indicated by the id
Positive acknowledgement that the request has been made durable by the respondent.
Positive acknowledgement that the request has been made durable by the respondent.
The request being positively acknowledged.
The unique identifier of the respondent
Negative acknowledgement that the request has been rejected by the respondent.
Negative acknowledgement that the request has been rejected by the respondent. The progress in the reply gives an indication of the reason: either the respondent has made a higher promise else the respondent has committed the proposed slot.
The request being negatively acknowledged
The unique identifier of the respondent
The high commit mark and last promise of the responding node.
Base type for a response to an accept message.
Tracks the responses to an accept message and when we timeout on getting a majority response
Tracks the responses to an accept message and when we timeout on getting a majority response
The point in time we timeout.
The accept that we are awaiting responses.
The known responses.
The logical number used to discriminate messages as either higher or lower.
The logical number used to discriminate messages as either higher or lower. Numbers must be unique to _both_ the node in the cluster *and* paxos prepare. Physically it is 64bits with high 32bits an epoch number and low 32bits a node unique identifier. The number will be fixed for a stable leader so it also represents a leaders term.
Used by candidate leaders to "go higher" than prior or competing leaders. No guarantees are made as to this number; there may be gaps between values issued by a node and there may be collisions between dueling leaders.
node unique number which must be unique to an agent within the cluster (e.g. set from unique configuration or parsed from DNS name ’node0’, ’node1'). This value is used to tie break between dueling leaders. Safety of the algorithm requires that this value must be unique per cluster.
codacy.com complains about using var in tests or using '.get' on atomics so this is our own box mainly used for testing purposes as it doesn't seem worth a new module nor a new dependency to avoid having to add this into the main codebase.
We perform consensus over instances of CommandValue.
Commit messages indicate the highest committed log stream number.
Commit messages indicate the highest committed log stream number. The leader shall heartbeat this message type to indicate that it is alive. Followers must:
1. Commit the specified message in the log index if-and-only-if all previous values have been committed in order. 1. Request retransmission of any messages not known to have been committed at lower log index slot.
Note that the leader must commit messages in log index order itself which implies that any prior slots user the same leader number have also been committed by the leader.
Identifies the unique accept message, and hence unique value, which is being committed into the identified slot.
A value which changes for each heartbeat message which indicates that the leader is alive.
Identifies a unique leader epoch and log index “slot” into which a value may be proposed.
Identifies a unique leader epoch and log index “slot” into which a value may be proposed. Each leader must only propose a single value into any given slot and must change the BallotNumber to propose a different value at the same slot. The identifier used for a given slot will be shared across prepare, accept and commit messages during a leader take-over. The ordering of identifiers is defined by their log index order which is used to commit accepted values in order. TODO how can from differ from number.nodeIdentifier?
The node sending the message.
The paxos proposal number used for comparing messages, or values, as higher or lower than each other. This value will be fixed for a stable leadership.
The contiguous log stream position, or “slot”, into which values are proposed and committed in order.
Durable store for the replicated log.
Durable store for the replicated log. Methods load and save must make durable the bookwork of the progress made by the given cluster node. The accept and accepted methods store value message at a given log index. An implementation could use a BTree else a local database.
http://stackoverflow.com/a/5597750/329496
Response to a client when the nodes has lost its leadership whilst servicing a request during a fail-over due to either a network partition or a long stall.
Response to a client when the nodes has lost its leadership whilst servicing a request during a fail-over due to either a network partition or a long stall. The outcome of the client operation indicated by msgId is unknown as the operation may or may not be committed by the new leader. The application will have to query data to learn whether the operation did actually work. Note that semantically this is no different from sending a tcp request to an open socket and not getting back a response; its not known whether the request was processed as there has been neither positive nor negative acknowledgement. Since we don't know if it is safe to retry the operation nor how to query to check it the host application will have to decided what to do next. Note that this may be thrown for read only work if the application used strong or single reads as those avoid returning stale data which may occur doing a leader failover.
The node replying that it is has lost the leader.
The client message which the node is responding to.
Response to a client when the nodes is not currently a follower.
Response to a client when the nodes is not currently a follower. As the leader is write bottleneck applications that can tolerate stale can reads can opt to spread some reads across all the replicas. This message is return in response to such follower reads. The client can retry other nodes (or even this node) until it gets a response.
The node replying that it is has become the leader.
The client message which the node is responding to.
Response to a client when the node is not currently the leader.
Response to a client when the node is not currently the leader. The client should retry the message to another node in the cluster. Note the leader may have crashed and the responding node may become the leader next.
The node replying that it is not the leader.
The client message identifier which the node is responding to.
This algebraic type holds the state of a node in the cluster.
This algebraic type holds the state of a node in the cluster.
The highest promised and highest committed progress of a node in the cluster.
The last heartbeat value seen from a leader. Note that clocks are not synced so this value is only used as evidence that a stable leader is up whereas the paxos number and committed slot are taken as authoritative that a new leader is making progress.
The next randomised point in time that this node will timeout. Followers timeout on Commit messages and become a Recoverer. Recoverers timeout on PrepareResponses and AcceptResponses. Leaders timeout on AcceptResponses.
The current size of the cluster.
The outstanding uncommitted proposed work of the leader take over phase during the recovery of a leader failover. Each key is an identifier of a prepare for which we are collecting a majority response to determine the highest proposed value of the previous leader if any.
The leaders paxos number when leading.
Tracking of responses to accept messages when Recoverer or Leader. Each key is an identifier of the command we want to commit. Each value is a map of the ack/nacks of each cluster node with a timeout.
The client work outstanding with the leader. The map key is the accept identifier and the value is a tuple of the client command and the client ref.
We would like to log per agent rather than per class/trait so we pass the logger around.
We would like to log per agent rather than per class/trait so we pass the logger around. This API happens to follow Akka logging
Marker trait for messages
Paxos process roles
Once consensus has been reached we deliver CommandValues in consensus order with the possibility of repeats during crash recovery.
Once consensus has been reached we deliver CommandValues in consensus order with the possibility of repeats during crash recovery.
An id number which can be use dto deduplicate repeated deliveries that may happen during crash recovery.
The value which has been chosen by the consensus protocol.
Prepare is only sent to either establish a leader else to probe for the uncommitted values of a previous leader during the leader take-over phase.
Prepare is only sent to either establish a leader else to probe for the uncommitted values of a previous leader during the leader take-over phase. Followers must:
1. Check the BallotNumber of the Identifier against the highest value previously acknowledged; if the request is lower acknowledged negatively acknowledge (“nack") it. 1. Check the logIndex of the Identifier against the highest committed logIndex; if the request is lower nack it. 1. If the BallotNumber of the Identifier is higher the then previously acknowledged the node must make the new number durable and promise to nack any messages with a lower BallotNumber The positive acknowledgement ("ack") must return the highest uncommitted Accept message with the same log index or None if there is no uncommitted value at that slot.
Positively acknowledge a Prepare message.
Positively acknowledge a Prepare message. See PrepareResponse
The highest uncommitted log index accepted by the responding node.
Negatively acknowledge a Prepare message.
Negatively acknowledge a Prepare message. See PrepareResponse
Base type for a response to a prepare message.
Base type for a response to a prepare message. It provides additional information beyond that prescribed by the core Paxos alogirth which is used during the leader takeover protocol and to prevent unnecessary leader failover attempts.
The progress of a node is the highest promise number and the highest committed message.
The progress of a node is the highest promise number and the highest committed message.
Highest promise made by a node
Highest position and highest number committed by a node
Requests retransmission of accept messages higher than a given log message
Requests retransmission of accept messages higher than a given log message
The node unique id which is sending the request
The node unique id to which the request is to be routed
The log index last committed by the requester
Response to a retransmit request
Response to a retransmit request
The node unique id which is sending the response
The node unique id to which the request is to be routed
A contiguous sequence of committed accept messages in ascending order
A contiguous sequence of proposed but uncommitted accept messages in ascending order
The id of the ClientRequestCommandValue being responded to.
The
Scheduled message used to trigger timeout work.
Scheduled message use by a leader to heatbeat commit messages.