Raft

v0.1.0

Raft v0.1.0 Raft.Server

Link to this section Summary

Types

members()
state()

Functions

callback_mode()
candidate(msg, req, state)
child_spec(opts)
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)

TODO: Implement this workflow.

  • Pull logs out of storage
  • Pull current term out of storage
  • Set a new election timeout
  • Find the most recent config change (start from most recent snapshot if we have one)
  • Restore state:
    • set last index
    • set last_log
    • set current term
    • set the configuration
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)
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)

TODO: Implement this workflow.

  • Pull logs out of storage
  • Pull current term out of storage
  • Set a new election timeout
  • Find the most recent config change (start from most recent snapshot if we have one)
  • Restore state:
    • set last index
    • set last_log
    • set current term
    • set the configuration
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.