A new year, a new tool set! I am plunging myself into Akka. The first time I heard from Akka was in 2012. It immediately got my attention, but somehow I never really got engaged. But that is going to change! I have set my first steps on the road to Akka and it seems like this is going to be an interesting journey!
What is Akka?
Besides a mountain range in Sweden? Well, the documentation say it all: Akka is a set of libraries for designing high performing multi-threaded and possibly distributed applications. That is quite a promise to make! Furthermore, Akka should enable developers to deliver truly reactive systems. But most of all, Akka could be seen as a modern implementation of the ‘actor model of concurrency’.
Well, I have heard about it some long time ago, but never really knew what the fuzz is all about. The actor model of concurrency used to be a theoretical model for concurrent computation. It was proposed in a paper called “A Universal Modular Actor Formalism for Artificial Intelligence” in 1973. The actor model proposes a mindset to tackle the difficulties of concurrent/parallel programming by advocating that ‘everything is an actor’.
Actors
The actors in the actor model can be see as the ‘concurrent primitives’. In other words, they are the smallest units in a concurrent system. An actor should be seen as a container for both state and behavior. Then how is this all different from your good old objects? Well, technically speaking, java actors are of course java objects, but the difference is in how Akka forces you to use them, how you should use them.
In order to really understand well, lets reflect on what makes concurrent programming so damn hard. Along with shivers down the spine, there are a few points that immediately come to mind:
Shared state
Managing shared state
Communication between threads
These are the first ones that come to mind. Shared state and managing access to shared state… that is hard. Before you know it, your code is flooded with ‘volatile’ and ‘synchronized’. These are hard problems to solve and mistakes are easily made which can wreak havoc on the consistency and correctness of your application.
Solitude and encapsulation to the rescue
When you think of it, the biggest issue with concurrent programming is the shared state. When objects with state have a reference to another object, they can just invoke any public behavior of that object and usually through behavior, objects can change each other’s state. This is all fun and games until multiple threads are forcing their way through the object graph, changing state and what not. Well, in an actor based system, you don’t have that problem.
Say what now?
In an actor based system, you don’t have that problem. This is because you cannot directly read from an actor, you cannot directly invoke behavior of an actor, heck, you shouldn’t even be directly making an instance of an actor.
Think of actors as persons with a task in complete isolation of each other. They can send messages to each other but they cannot shake hands. The way actors communicate is through messages. And every actor has his own mailbox (which is called an ActorRef ), where it picks the next message to process. That is encapsulation on a totally different level! All of this to protect the data, the state of an actor against other actors or objects!
This also makes actors asynchronous. An actor accepts messages, does processing and then replies when it is ready. This implies that the sending party does not block the application. It does not have to wait for a reply. The sender can just go on with its own business and when a reply eventually comes in, the sender can deal with it then. Cool stuff right?
Hierarchy and supervising
Actors really shine when they are put into a hierarchy. An actor always belongs to a parent actor, or rather: a supervising actor. There is of course one exception to that rule, namely the root actor. There always is one that will be the first. An advantage of having a hierarchy is the possibility to delegate tasks to child actors but also to possibility to supervise those child actors. A supervisor knows what to do when one of its child actors has an error or just outright stops working. It makes managing the lifecycle of an actor easy and this makes for very robust applications!
Wrap up
To wrap up this first post on Akka, a small summary:
Akka is set of libraries supporting ‘the actor model of concurrency’.
An Actor is basically a container of state and behavior, carefully encapsulated to prevent other objects and actors from messing with its data.
Actors communicate with messages
Actors shine in a hierarchy so parent actors can manage the lifecycle of their children
I really like Akka so far. The actor model works well for designing applications so far. If you are eager to dive into some code, check my examples on github . More will follow, i ll try and make them as explanatory as possible.