package node
- Alphabetic
- Public
- All
Type Members
-
final
case class
AddressedRequest[A](requests: Iterable[(NodeId, RaftRequest[A])]) extends RaftNodeResult[A] with Product with Serializable
A sequence of requests to send out as a result of a RaftNode having processed an event or message
A sequence of requests to send out as a result of a RaftNode having processed an event or message
- A
the log type
- requests
the requests to send, coupled w/ the intended recipient
-
final
case class
AddressedResponse(replyTo: NodeId, msg: RaftResponse) extends RaftNodeResult[Nothing] with Product with Serializable
Combines a 'replyTo' node with a response
Combines a 'replyTo' node with a response
- replyTo
the node to which this response should be targeted
- msg
the response, presumably to a request sent from the 'replyTo' node
- final case class CandidateNodeState(id: NodeId, initialState: CandidateState) extends NodeState with Product with Serializable
-
case class
CandidateState(term: Term, votesFor: Set[NodeId], votesAgainst: Set[NodeId], clusterSize: Int) extends Product with Serializable
Contains the functions for when a node becomes a candidate due to a heartbeat timeout
- final case class FollowerNodeState(id: NodeId, leader: Option[NodeId]) extends NodeState with Product with Serializable
-
final
case class
LeaderCommittedResult[A](committed: Seq[LogCoords], response: RaftNodeResult[A]) extends RaftNodeResult[A] with Product with Serializable
This was introduced after having first just having: 1) AddressedRequest 2) AddressedResponse 3) NoOpResult
This was introduced after having first just having: 1) AddressedRequest 2) AddressedResponse 3) NoOpResult
which seemed ok. Unfortunately we have situations (namely when the node is a leader) when we want more information about e.g. commit/log append data so we can expose that data to a client.
We could start introducing 'Either', 'Xor', etc types, but I'd like to avoid: 1) the extra wrapping penalty 2) overly-complex return types
though the second is at the expense of scenarios which have to pattern-match on the result types
- A
the log type
- committed
if an riff.raft.messages.AppendEntriesResponse resulted in committing a log entry, these are the coordinates of those committed entries
- response
either a no-op (e.g. log) result or potentially an AddressedRequest to send the next data required
- final case class LeaderNodeState(id: NodeId, clusterView: LeadersClusterView) extends NodeState with Product with Serializable
-
class
NIOPersistentState extends PersistentState
Some PersistentState written to the file system using java.nio
-
sealed
trait
NoOpResult extends RaftNodeResult[Nothing]
Marker interface for a no-op result of a node having processed an event or message.
Marker interface for a no-op result of a node having processed an event or message.
At the moment there is just a 'log message' implementation, but we could make the results more strongly-typed if needed (e.g. as a candidate advances through its votes, or the detail from some invalid action)
-
final
case class
NodeAppendResult[A](appendResult: LogAppendResult, request: AddressedRequest[A]) extends RaftNodeResult[A] with Product with Serializable
Like LeaderCommittedResult this was added so we could explicitly expose the extra information when appending data as a leader as a result of an riff.raft.messages.AppendEntries request.
Like LeaderCommittedResult this was added so we could explicitly expose the extra information when appending data as a leader as a result of an riff.raft.messages.AppendEntries request.
- A
the log type
- appendResult
result of appending some data to this node
- request
the request(s) (as wrapped in a AddressedRequest) to send
- sealed trait NodeRole extends AnyRef
-
sealed
trait
NodeState extends AnyRef
Represents an in-memory state matching a node's role
-
class
Peer extends AnyRef
The view of a peer in the cluster
-
trait
PersistentState extends AnyRef
Keeps track of a node's internal state: 1) what term it is 2) who the chuff it voted for
-
trait
RaftCluster extends AnyRef
Represents something which knows about the peers in the cluster.
Represents something which knows about the peers in the cluster. This is typically (and recommended to be) a fixed size cluster.
The NodeKey themselves are often just String identifiers used as a look-up for a means of communicating with that peer, but could be the peer transport itself, provided it has a good hashCode/equals
-
trait
RaftMessageHandler[A] extends AnyRef
This interface represents a stateful black-box of a raft node.
This interface represents a stateful black-box of a raft node.
It is typically NOT THREAD SAFE, but rather something which simply something which can take inputs and produce outputs
- A
the type of data which is appended to the log (could just be a byte array, some union type, etc)
-
class
RaftNode[A] extends RaftMessageHandler[A] with TimerCallback[RaftNodeResult[A]] with AutoCloseable
The place where the different pieces which represent a Raft Node come together -- the glue code.
The place where the different pieces which represent a Raft Node come together -- the glue code.
I've looked at this a few different ways, but ultimately found this abstraction here to be the most readable, and follows most closely what's laid out in the raft spec.
It's not too generic/abstracted, but quite openly just orchestrates the pieces/interactions of the inputs into a raft node.
-
sealed
trait
RaftNodeResult[+A] extends AnyRef
Represents all possible results of a RaftNode having processed an event or message
Represents all possible results of a RaftNode having processed an event or message
- A
the log type
- case class RecordingMessageHandler[A](underlying: RaftMessageHandler[A]) extends RaftMessageHandler[A] with StrictLogging with AutoCloseable with Product with Serializable
-
trait
RoleCallback extends AnyRef
This is provided as a convenience to be added to a riff.raft.node.RaftNode for anything which cares about role transitions for a particular node.
This is provided as a convenience to be added to a riff.raft.node.RaftNode for anything which cares about role transitions for a particular node.
That behaviour could be done by subclassing the RaftNode, but subclassing brings in its own challenges/considerations.
By making this more explicit, in addition to obviating the need to to subclass riff.raft.node.RaftNode, it hopefully will make the code more navigable/readable
Value Members
- object AddressedRequest extends Serializable
- object Candidate extends NodeRole with Product with Serializable
- object Follower extends NodeRole with Product with Serializable
- object Leader extends NodeRole with Product with Serializable
- object LeaderNodeState extends Serializable
- object LeadersClusterView
- object NIOPersistentState
- object NoOpResult
- object Peer
- object PersistentState
- object RaftCluster
- object RaftNode
- object RoleCallback