(append-entries-event raft-state args callback)
(apply-config-change raft-state req)
(apply-config-change raft-state req server-state)
(apply-config-change raft-state req server-state callback)
(become-follower raft-state new-term new-leader-id cause)
Transition from a leader to a follower
Transition from a leader to a follower
(call-monitor-fn state-after op data state-before start-time-ns)
Internal - calls monitor function safely and calcs time.
Internal - calls monitor function safely and calcs time.
(config-change raft-state data callback)
(conj-distinct val add)
(event-chan raft)
Returns event channel for the raft instance.
Returns event channel for the raft instance.
(initialize-config {:keys [this-server] :as raft} data)
When a new leader is elected, we make sure everyone has the same config
When a new leader is elected, we make sure everyone has the same config
(install-snapshot raft-state snapshot-map callback)
Installs a new snapshot, does so in parts. Parts should always come serially, so can just append new part. Once complete, it is registered, until then it is not referenced and therefore will not be accessed by raft.
It is possible a new leader can be elected prior to finishing the last leader's snapshot. If so, we will be receiving a new snapshot from the new leader, and can abandon this effort. Because of this, it cannot be guaranteed that historical snapshots on disk are complete - only trust the one official registered snapshot in the raft-state.
It is a good practice when receiving part 1 to delete any existing file if exists. It is possible two leaders have same snapshot index and one interrupted process can exist while a new one starts, inadvertently concatenating two snapshots.
Installs a new snapshot, does so in parts. Parts should always come serially, so can just append new part. Once complete, it is registered, until then it is not referenced and therefore will not be accessed by raft. It is possible a new leader can be elected prior to finishing the last leader's snapshot. If so, we will be receiving a new snapshot from the new leader, and can abandon this effort. Because of this, it cannot be guaranteed that historical snapshots on disk are complete - only trust the one official registered snapshot in the raft-state. It is a good practice when receiving part 1 to delete any existing file if exists. It is possible two leaders have same snapshot index and one interrupted process can exist while a new one starts, inadvertently concatenating two snapshots.
(into-chan coll c)
Conjoins all available entries in channel to supplied collection.
Conjoins all available entries in channel to supplied collection.
(new-election-timeout raft)
Generates a new election timeout in milliseconds.
Generates a new election timeout in milliseconds.
(register-callback-event raft-state command-id timeout-ms callback)
Registers a single-arg callback to be executed once a command with specified id is committed to state machine with the result the state machine replies.
Registers a single-arg callback to be executed once a command with specified id is committed to state machine with the result the state machine replies.
(request-vote-event raft-state args callback)
Grant vote to server requesting leadership if:
If we will reject vote because the log index is not as current as ours, and we are the current leader, immediately kick off a request vote of our own as it is likely a follower was just slow receiving our append entries request and this can get things back on track quickly.
Grant vote to server requesting leadership if: - proposed term is >= current term - we haven't already voted for someone for this term - log index + term is at least as far as our log. If we will reject vote because the log index is not as current as ours, and we are the current leader, immediately kick off a request vote of our own as it is likely a follower was just slow receiving our append entries request and this can get things back on track quickly.
(reset-server-state raft-state)
Called when we become a follower to clear out any pending outgoing messages.
Called when we become a follower to clear out any pending outgoing messages.
(safe-callback callback data)
Executes a callback in a way that won't throw an exception.
Executes a callback in a way that won't throw an exception.
(send-queued-messages raft-state)
Sends all queued messages if we aren't waiting for responses.
Sends all queued messages if we aren't waiting for responses.
(update-commits raft-state leader-commit)
Process new commits if leader-commit is updated. Put commit results on callback async channel if present. Update local raft state :commit
Process new commits if leader-commit is updated. Put commit results on callback async channel if present. Update local raft state :commit
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close