Actor Reference and Messaging Mechanism

You can write concurrent programs on a single CPU (single execution core) machine where only one task can execute at a given point of time. Typically multiple tasks are executed in a time-slice manner, where a scheduler (such as the JVM) will guarantee each process a regular “slice” of operating time.

An ActorSystem is a heavyweight structure that will allocate 1. . .N threads, so create one per logical subsystem of your application. For example, you can have one actor system to handle the backend database, another to handle all the web service calls, and so forth. Actors are very cheap. A given actor consumes only 300 bytes so you can easily create millions of them.

Akka actors are started asynchronously when they’re passed into the actorOf method using a Props. At the ActorSystem level of your application, you create actors by calling the system.actorOf method. Within an actor, you create a child actor by calling the context.actorOf method.

When you create an actor in Akka, you never get the direct reference to the actor. Instead you get back a handle to the actor called ActorRef (actor reference). The foremost purpose of ActorRef is to send messages to the actor it rep- resents. It also acts as a protection layer so you can’t access the actor directly and mutate its state. ActorRef is also serializable, so if an actor crashes, as a fault-handling mechanism, you can possibly serialize the ActorRef, send it to another node, and start the actor there. Clients of the actor will not notice.

When an actor receives a message from another actor, it also receives an implicit reference named sender, and it can use that reference to send a message back to the originating actor.

To send a message to an actor mailbox the ActorRef first sends the message to the MessageDispatcher associated with the actor (which in most cases is the MessageDispatcher configured for the actor system). The MessageDispatcher immediately queues the message in the mailbox of the actor. The control is immediately returned to the sender of the message.

The message dispatcher always makes sure that a single thread always executes a given actor. It might not be the same thread all the time but it is always going to be one. This is a huge guarantee to have in the concurrent world because now you can safely use mutable state inside an actor as long as it’s not shared.

Future and Promise provide abstractions to perform concurrent operations in a nonblocking fashion. They are a great way to create multiple concurrent and parallel computations and join them to complete your job. Think of Future as a proxy object that you can create for a result that will be available at some later time.You can use Promise to complete a Future by providing the result.

An important point to note here is that it is safe to use mutable state inside an actor because the actor system will ensure that no two threads will execute an instance of an actor at the same time. You must make sure you don’t leak the state outside the actor.

Creating self-contained immutable mes- sages and determining the communication between actors are important steps when working with actors. It’s also important to understand that when working with actors, all the communication happens through messages, and only through messages.