Distributed Hash Table

Local Hash Table

implementation details

First, read about state actors.

The 1:1 API implementation between actors and their inner table is achieved by internally blocking on an ask from riker patterns.


The actor ref methods implementing HashTable sends messages to itself.

Calling table_actor_ref.commit(entry) looks like this:

  1. the actor ref constructs a Protocol::PutPair message including the entry
  2. the actor ref calls its own ask method, which builds a future using riker's ask
  3. the actor ref blocks on its internal future
  4. the referenced actor receives the Commit message and matches/destructures this into the entry
  5. the entry is passed to the commit() method of the inner table
  6. the actor's inner table, implementing HashTable, does something with commit (e.g. MemTable inserts into a standard Rust, in-memory HashMap)
  7. the return value of the inner table commit is inserted into a CommitResult message
  8. the CommitResult message is sent by the actor back to the actor ref's internal future
  9. the actor ref stops blocking
  10. the CommitResult message is destructured by the actor ref so that the return of commit satisfies the HashTable trait implementation

Riker ask returns a future from the futures 0.2.2 crate.

table_actor.block_on_ask() calls block_on and unwrap against this ask.

Both the block and the unwrap should be handled better in the future.

suggest an edit