Anyone who has done multithreading in the past won’t deny how hard and painful it is to manage multithreaded applications. I said manage because it starts out simple and it became a whole lot of fun once you start seeing performance improvements. However, it aches when you see that you don’t have a easier way to recover from errors in your sub-tasks OR those zombie bugs that you find hard to reproduce OR when your profiler shows that your threads are spending a lot of time blocking wastefully before writing to a shared state.
I prefer not to talk about how Java concurrency API and their collections made it better and easier because I am sure if you are here, you probably needed more control over the sub-tasks or simply because you don’t like to write locks and synchronized blocks and would prefer a higher level of abstraction.
In this series of Akka Notes, we would go through simple Akka examples to explore the various features that we have in the toolkit.
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 doesnt 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 mails 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 be
createdin 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….
| Reference: | Akka Notes – Introducing Actors from our JCG partner Arun Manivannan at the Rerun.me blog. |
Very good article. There is just one flaw. I am married to a University Professor, and you make the fatal assumption that they are that organized. ;)
Keep the great articles coming.
hahaha. Thanks a lot Stephen. Glad you liked it.