Dispatchers

What makes Akka “tick”

Like the docs say, dispatchers are what make Akka tick. Dispatchers are responsible for selecting an actor and it’s messages and assigning them the CPU. In this post we’re gonna look at different types of dispatchers and how you can use one in your application.

Types of Dispatchers

There’s a number of different dispatchers that Akka provides readily and also lets you write your own implementation, should you need.

There’s three dispatchers that come out of the box — dispatcher (default), pinned dispatcher, and balancing dispatcher.

Dispatcher

This is the default dispatcher that is used when you don’t specify anything. This dispatcher is backed by a thread pool, creates one mailbox per actor, and can easily be shared between a number of actors of different types.

This dispatcher will pick an actor and assign it a dormant thread from it’s pool. The actor will then process a certain number of messages from its mailbox before relinquishing the thread.

It is designed to be used when you have non-blocking (async) code in your actor.

Pinned Dispatcher

This dispatcher assigns a dedicated thread per actor and is backed by a thread pool where each pool has one thread only. Every actor will have its own mailbox. Since each actor has its own thread, this dispatcher should be used when the actors perform long running calculations or database calls. The assigned thread is deallocated after a certain period of inactivity.

This dispatcher is not shareable with other actors.

Balanced Dispatcher

The balance dispatcher redistributes the work among idle actors. It does so by creating one mailbox that is shared between the actors.

This dispatcher is shareable only between actors of the same type.

Why use dispatchers?

We use dispatchers to implement bulkheading and work sharing.

Bulkheading is a software engineering strategy that prevents damage from one part of the application from affecting others. By using dispatchers, we can ensure that a set of actors do not hog up the resources and end up starving the others.

For example, with dispatchers, we can ensure that a set of actors serving high priority requests get more threads than the ones serving low priority requests and should one of the low priority requests cause the system to go haywire, it wouldn’t starve the ones serving higher priority requests.

Work sharing lets us use our available resources to the maximum. For example, the balanced dispatcher looks for an idle actor and dispatches its messages for processing.

Adding a dispatcher to your application

You can add a dispatcher to your application completely via the configuration file or via a combination of code and configuration file. In the latter, you define the dispatcher in the configuration file and assign it to the actor in code. I, personally, prefer the latter and that’s what I’ll show in this example.

Begin by creating a file named “application.conf” under the “resources” folder of your application.

Here we’re creating a default dispatcher which will have a minimum of 8 threads (core-pool-size-min * core-pool-size-factor) and a maximum of 16 threads (core-pool-size-max * core-pool-size-factor). Each actor will process 10 messages before relinquishing the thread. A negative mailbox capacity means an unbounded mailbox.

Next we need to load the configuration and pass the config object to the ActorSystem. Update the code for the main app to look like the following:

Finally, update the SuperviorActor to assign the dispatcher to GreetingsActor by updating the code as follows:

That’s it. You’ve added a dispatcher to your application.