[Actor model] Some real-world implementation details from AKKA

Found this talk on YT recently, my comments + notes below:

Introduction to the Actor Model for Concurrent Computation - John Murray

Actor is:

• persistent
• has internal state
• asyc
• Independent event-loop + memory
• Mailbox (receive message)
• React in FIFO order

Well,
actor model is concurrent with regard to a system of actions.
actor model is Not concurrent with regard to data.
(surely we can do implement concurrent thread inside one actor.)

Using channel as mutex to single variable

So, how to make a mutable variable access by multiple threads?

In Golang, we have channel.

• Create a channel with the length of 1.
• Put the mutable variable in, and mutiple goroutines have access to that channel.
• However, only one goroutine can successful retrieve the mutable varible inside the length of 1 channel, other goroutines since the channel has no value, it will block.
• This acts as a MUTEX for goroutines.
• Once the goroutine which having the mutable variable changed,
  it puts it back to the channel thus other goroutines can access.

Actor can:

• create more Actors
• receive messages and response
• make local decisions
• perform arbitrary, side-effecting action
• send messages
• respond to the sender 0 or more times
  (to clearfy here, by "respond" means
  send message to the sender Actor
  Not duplex channel respond)
• Process exactly one message at a time

Actor communication is:

• No channels or internediaries (such as in CSP, e.g. golang)
• "best effor" delivery
• at-most-once delivery
• Messages can take arbitrary long to be delivered (has no concept of time)
• No message ordering guarantees

Actor address:

• identify the actor
• may also represent a proxy / forwarder to an Actor
• contains location and transport information
• don't care where the Actor lives
  (can be inside the same process, different nodes, different containers, etc)
• one address may represent many Actors(pool)

Error handling:

• Supervision
• the running state of an Actor is monitored and managed by another Actor(the Supervisor)
• Supervision has:
• constantly monitors running state of actor
• can perform actions based on the state of the Actor( e.g unhandled error, restart Actor)
  (In Golang, we take advantage of context.Context)
• transparent life-cycle management
• addresses do not change during restarts
  (we implemented with Actor's hash(name + uuid + hostname) as 'address')
  BE WARE.
  This only has meaning iff Actor is not pure, which is STATEFUL.
• Persist state into local sqlite, loaded with (name + uuid)
• mailboxes are persisted outside the Actor instances (Auh, K.I.S.S)
  I doubt the use of Supervisor idea.
  Think about this, does the Sender care how the Receiver act when it receives the message? ;-P

 

Implement Address contains these as a group:

• mailbox
• Actor

Anti use-case:

• Working on a non-concurrent system
• performance critical applications
• non-concurrent communication is involved
• no mutable state

Draw backs:

• too many Actors
• testing
• debugging

Extra material:
Don't use Actors for concurrency


CRDT:
https://medium.com/@istanbul_techie/a-look-at-conflict-free-replicated-data-types-crdt-221a5f629e7e