For developers who have experienced the problems with creating and managing multithreaded applications and are looking for a higher level of abstraction to get away from threads and locks, Arun Manivannan has written a series of, so far, six blog posts explaining the principles of Actor model using an picture-rich visualization and simple Akka examples to explore the various features that are available in the Akka toolkit.
Starting with a bird's eye view of Actors, Arun describes them comparing with people:
Treat Actors like People. People who don't talk to each other in person. They just talk through mails.
Passing messages is the basic block of the Actor model and using a student and a teacher as an example Arun describes the basic flow as:
- A student sends a mail to a teacher, a mail that cannot be changed once sent.
- The teacher will check her mailbox finding the mail at a time she sees fit.
- The teacher sends a mail back to the student at some later time, also immutable once sent.
- The student later on decides to checks his mailbox and then finds the mail, (he has not been standing by the mailbox waiting for an answer).
Besides one-way messaging, when a message is sent without expecting or waiting for a response, an Actor is also capable of sending a response back to the sender, in a request-response cycle.
When introducing concurrency into the example, with several students and teachers and each student sending mail to all teachers nothing is changed since each participant has their own mailbox with each mail read in the order they arrive. Failover, when e.g. one teacher fails to receive mails, is handled by a new teacher taking over for the failing one.
The lifecycle of an Actor is quite basic beginning with a constructor and a preStart method called before the Actor starts servicing messages, by the receive method. Finally an Actor put into terminated state by a postStop method. Arun notes that the lifecycle is similar to the one of e.g. a Java servlet with some minor discrepancies.
Actors are hierarchical with every Actor being a child of another Actor. Arun compares this with a file system, with a few folders at the top and an increasing number as you follow the hierarchy down. Normally children are created by the parent to handle subtasks or for isolating especially error-prone tasks thus enabling a system to recover from a failure. An important part of Actor’s fault tolerance actually comes with this ability for a parent to manage the life of child actors.
Other areas Arun looks into includes logging, testing, configuration and a project including all code examples can be downloaded from github.
Besides Akka, for Java and Scala, there are also Actor model implementations for e.g. .Net, two of them with a difference in approach.