Raft

v0.2.1

Raft v0.2.1 Raft.Server

The Server module provides the raft fsm.

Link to this section Summary

Types

members()
state()

Functions

callback_mode()
candidate(msg, req, state)
child_spec(opts)

This defines the child spec correctly

current_leader(server)

Returns the name of the server that is believed to be the leader. This is not a consistent operation and during a network partition its possible that the server doesn’t know who the latest elected leader is. This function should be used for testing and debugging purposes only

follower(event, req, state)
handle_event(event_type, event, current_state, state)

Whenever a GenStateMachine in callback mode :handle_event_function (the default) receives a call, cast, or normal process messsage, this callback will be invoked

init(arg)

Initializes the state of the server. If log files already exist for this server name then it reads from those files to get the current configuration, term, etc

leader(msg, event, state)
read(peer, cmd, timeout \\ 3000)

Reads the current state from the state machine. This is done in a highly consistent manner. Reads must be executed on a leader and the leader must confirm that they have not been deposed before processing the read operation as described in the raft paper, section 8: Client Interaction

set_configuration(peer, configuration)
start_link(arg)

Starts a new server

status(sm)

Gets the current status of the server

up_to_date?(cand_term, cand_index, our_term, our_index)
write(peer, cmd, timeout \\ 3000)

Applies a new log to the application state machine. This is done in a highly consistent manor. This must be called on the leader or it will fail

Link to this section Types

Link to this type members() 
members() :: %{required(atom()) => pid()}
Link to this type state() 
state() :: :leader | :follower | :candidate

Link to this section Functions

Link to this function callback_mode()
Link to this function candidate(msg, req, state)
Link to this function child_spec(opts)

This defines the child spec correctly

Link to this function current_leader(server) 
current_leader(atom()) :: atom()

Returns the name of the server that is believed to be the leader. This is not a consistent operation and during a network partition its possible that the server doesn’t know who the latest elected leader is. This function should be used for testing and debugging purposes only.

Link to this function follower(event, req, state)
Link to this function handle_event(event_type, event, current_state, state)

Whenever a GenStateMachine in callback mode :handle_event_function (the default) receives a call, cast, or normal process messsage, this callback will be invoked.

This function can optionally throw a result to return it.

See the erlang documentation for a complete reference.

Callback implementation for GenStateMachine.handle_event/4.

Link to this function init(arg)

Initializes the state of the server. If log files already exist for this server name then it reads from those files to get the current configuration, term, etc.

Link to this function leader(msg, event, state)
Link to this function read(peer, cmd, timeout \\ 3000)

Reads the current state from the state machine. This is done in a highly consistent manner. Reads must be executed on a leader and the leader must confirm that they have not been deposed before processing the read operation as described in the raft paper, section 8: Client Interaction.

Link to this function set_configuration(peer, configuration)
Link to this function start_link(arg) 
start_link({Raft.peer(), Raft.Config.t()}) :: {:ok, pid()} | {:error, term()}

Starts a new server.

Link to this function status(sm) 
status(pid()) :: status()

Gets the current status of the server.

Link to this function up_to_date?(cand_term, cand_index, our_term, our_index)
Link to this function write(peer, cmd, timeout \\ 3000)

Applies a new log to the application state machine. This is done in a highly consistent manor. This must be called on the leader or it will fail.