What are Actors?
Akka's Actors follow the Actor Model (duh!).
Treat Actors like People. People who don't talk to each other in person. They just talk through mails.
Let's expand on that a bit.
1. Messaging
Consider two persons - A wise Teacher and Student. The Student sends a mail every morning to the Teacher and the wise Teacher sends a wise quote back.
Points to note :
- The student sends a mail. Once sent, the mail couldn't be edited. Talk about natural immutability.
- The Teacher checks his mailbox when he wishes to do so.
- The Teacher also sends a mail back (immutable again).
- The student checks the mailbox at his own time.
- The student doesn't wait for the reply. (no blocking)
That pretty much sums up the basic block of the Actor Model - passing messages.
2. Concurrency
Now, imagine there are 3 wise teachers and 3 students - every student sends notes to every other teacher. What happens then? Nothing changes actually. Everybody has their own mailbox. One subtle point to note here is this :
By default, Mails in the mailbox are read/processed in the order they arrived.
Internally, by default it is a ConcurrentLinkedQueue. And since nobody waits for the mail to be picked up, it is simply a non-blocking message. (There are a variety of built-in mailboxes including bounded and priority based. In fact, we could build one ourself too)
3. Failover
Imagine these 3 teachers are from three different departments - History, Geography and Philosophy.
History teachers replies with a note on an Event in the past, Geography teachers sends an Interesting Place and Philosophy teachers, a quote. Each student sends message to each teacher and gets responses. The student doesn't care which teacher in the department sends the reply back. What if one day, a teacher falls sick? There has to be at least one teacher handling the m
ails from the department. In this case, another teacher in the department steps up and does the job.
Points to note :
There could be a pool of Actors who does different things.
An Actor could do something that causes an exception. It wouldn't be able to recover by itself. In which case a new Actor could becreated in place of the old one. Alternatively, the Actor could just ignore that one particular message and proceed with the rest of the messages. These are called Directives and we'll discuss them later.
4. Multitasking
For a twist, let's assume that each of these teachers also send the exam score through mail too, if the student asks for it. Similarly, an the Actor could handle more than one type of message comfortably.
5. Chaining
What if the student would like to get only one final consolidated trivia mail instead of three?
We could do that too with Actors too. We could chain the teachers as a hierarchy. We'll come back to that later when we talk about Supervisors and revisit the same thought when we talk about Futures.
As requested by Mohan, let's just try to map the analogy components with the the components in the Actor Model.
Students and the Teachers becomes our Actors. The Email Inbox becomes the Mailbox
component. The request and the response can't be modified. They are immutable objects. Finally, the MessageDispatcher component in Actor manages the mailbox and routes the messages to the respective Mailbox.
Enough talk, let's cook up some code....
