Akka 2.4.11 was released two weeks ago. This release includes the new experimental Akka Remoting, codenamed ‘Artery’.

The Actor Model

This is a mathematical model of concurrent computation. “Actors” receive messages. They can decide how to respond, send a message in response, send more messages, and create more actors. The communication (message) and the sender (actor) are decoupled. The communication between actors is asynchronous and non-blocking. It is a lightweight event-driven process.

Implementing the Actor Model, actors are objects that encapsulate state and behaviour, and send state (in the form of immutable messages) to other actors. In an actor system, tasks are reduced to the smallest component so they can be handled in one piece, and without influencing other actors or blocking them. You can think of the actor system as being like an hierarchy of autonomous workers, with groups of actors handling low level tasks independently, and reporting up to interested supervisors.

An Akka Actor class example is:

import akka.actor.UntypedActor;
import akka.event.Logging;
import akka.event.LoggingAdapter;

public class MyUntypedActor extends UntypedActor {

  public void onReceive(Object message) throws Exception {
    if (message instanceof String) {
      getSender().tell(message, getSelf());
    } else

Example modified from the Akka documentation


Akka is a toolkit, a library of useful code that allows you to implement an actor system along with fault tolerance (supervisor hierarchies of actors, so you can write self-healing systems) and location transparency so it can work in a distributed environment. Used correctly, it is a platform that allows you to build scalable, fault-tolerant and concurrent applications. It is open source and available under the Apache 2 license. See the GitHub for the source code. Both Scala and Java are supported.

For an interesting discussion see this article.


Remoting relates to location transparency. Akka is designed to work in a distributed setting: the actor-to-actor interactions are asynchronous messages. So, functions can run within one JVM or across a group. Remoting is driven by configuration. Instead of APIs, think actor hierarchy and groups.

This works in the following way: an actor is represented to the outside with an actor reference, an ActorRef. This is an object that can be passed around, so actors can be restarted without needing to update references. Using remoting, the ActorRef is a unique identifier that contains the hostname and post information of the actor. This information can be passed around the network.

Artery is a reimplementation of a remoting module that aims to improve performance and stability. It is based on Aeron, which is a highly performant messaging system that allows you to send UDP packets with low latency. Artery aims for high-throughput and low-latency when passing messages between actors across a network.

The main changes with Artery are the use of UDP packets instead of TCP, and performance enhancements. The actor paths can be compressed to reduce overhead, and ByteBuffers are used to support faster serialisation and deserialisation. Actors can send smaller messages to each other, but messages containing more information. This makes it much easier to build a reactive, distributed system with simple concurrency and a small memory footprint. See the release notes for the full details.

Akka 2.4.11: Remoting with Artery

| Cloud| 1,060 views | 0 Comments
About The Author
- Katharine is a Java developer by trade, turned Community & Content Manager for Voxxed. Helping developers learn and share knowledge. Contact me at kbe@voxxed.com with any news, articles or tutorials.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>