Akka Roadmap

This roadmap is provided for informational purposes and is subject to change.

Releases are named after Jazz legends. Some are tagged with version numbers but most of them not - allowing us to splice in mid-term releases earlier to the user.

  1. Miles (Davis)
  2. (Charles) Mingus
  3. (John) Coltrane 
  4.  (Sonny) Rollins
  5. (Thelonious) Monk
  6. (Charlie) Parker
  7. Jaco (Pastorius)
  8. (Herbie) Hancock
  9. Dizzy (Gillespie)

For already completed milestones please refer to the end of this document.

Akka ‘Rollins’

ETA: end of 2015

Theme: Clustered elastic Akka for running applications in the Cloud

This milestone contains several features which are well separable; it is foreseen to make it available incrementally in multiple parts which correspond to major releases. The first part was already released with Akka 2.3 in March 2014.

Part II — Akka 2.4

Released on Sep 30, 2015

Make the switch to Java 8

In order to offer modern Java APIs and profit from the various improvements that were made to the JDK and the JVM we will the open-source Akka artifacts only for Java 8 and its new classfile format. Source-compatible uilds for JRE6 will be commercially available.

Finalize Persistence

We will build out the query capabilities of the Journal in order to fully support CQRS application architecture. The transport mechanism for events that then flow from the journal to the read (or Query) side of the application will be Akka Streams, so that the rich transformation and processing infrastructure can be brought to bear on this part of the design space as well.f

Cluster Improvements

We graduate DistributedPubSub, ClusterSingleton, ClusterClient and ClusterSharding from akka-contrib into fully supported modules. It will also be possible to join nodes into the cluster during a network partition, which is currently only possible by declaring the “other half” as permanently failed (a.k.a. DOWN).

Distributed Data

We incorporate Patrik Nordwall’s akka-data-replication add-on as Akka Distributed Data. This facility serves as an eventually consistent and fully available in-memory data storage solution and is based on CRDTs (Conflict-Free Replicated Data Types).

Akka “Gålbma” Development

“Gålbma” is the sami word for “three”.

In parallel to Akka 2.x evolution we will invest research effort into statically type-checked actor protocols, in essence parameterizing ActorRef with the type of messages it can accept. This is a breaking change, leading to a different and incompatible API and we will take our time to get this right before deprecating the current untyped Actor API—if we ever do that.

Akka ØMQ Removed

Due to several flaws in the integration module, we have decided to remove the akka-zeromq module from Akka 2.4, encouraging the community to take over its development.

Later in the 2.4.x cycle:

Akka Streams

An implementation of the Reactive Streams specification based on actors as execution model. This module underlies the HTTP implementation and also includes TCP, UDP and File IO providers. The operational parameters of the stream implementation (i.e. internal buffer sizes and prefetch windows) will be self-tuning.

Akka HTTP Layer

HTTP client and server support will be added on top of the Akka IO implementation in order to expose actors via a RESTful API and to allow actors to make REST calls. To this end Typesafe acquired the Spray framework, which will be ported into the Akka code base for this purpose, adding the following modules:

Akka ‘Monk’

Akka 2.5 or 3.0, depending on Binary Compatibility

ETA: 2016

Finalize Akka Typed

This will be the result of the Project Gålbma research. Fully type-checked actor interactions will be offered in parallel to the current untyped actor implementation. There are no plans at this point to remove the untyped actor facilities in the foreseeable future.

Remote Transport based on Akka Streams

Basing the remoting layer on actors instead of using Netty allows us to tailor aspects like thread usage and connection loss detection to Akka’s needs as well as opening up the possibility of implementing choices beyond TCP.

Performance Improvements

We will include regression tests and performance trend analysis into our build infrastructure and then work on making actors even faster and lighter than they are today. This will require the Project Gålbma to be far enough along to be able to profit from the internal simplifications it will bring.

Akka ‘Parker’

Akka ‘Jaco’

Akka ‘Hancock’

Akka ‘Dizzy’

Completed Milestones

Akka 2.0 (‘Miles’)

Released on March 6th, 2012

Akka 2.1 (‘Mingus’)

Released on December 23rd, 2012

Akka ‘Coltrane’

Released on July 9th, 2013

Theme: Clustered membership for running applications in the Cloud

Implementation is described in detail in the cluster specification.

Failure detection

The failure detector is responsible for trying to detect if a node is unreachable from the rest of the cluster. For this we are using an implementation of The Phi Accrual Failure Detector by Hayashibara et al. An accrual failure detector decouple monitoring and interpretation. That makes them applicable to a wider area of scenarios and more adequate to build generic failure detection services. The idea is that it is keeping a history of failure statistics, calculated from heartbeats received from the gossip protocol, and is trying to do educated guesses by taking multiple factors, and how they accumulate over time, into account in order to come up with a better guess if a specific node is up or down. Rather than just answering “yes” or “no” to the question “is the node down?” it returns a phi value representing the likelihood that the node is down.

Cluster membership

A cluster is made up of a set of member nodes. The identifier for each node is a hostname:port pair. An Akka application is distributed over a cluster with each node hosting some part of the application. Cluster membership and partitioning of the application are decoupled. A node could be a member of a cluster without hosting any actors. The cluster membership used in Akka is based on Amazon’s Dynamo system and particularly the approach taken in Basho’s‘ Riak distributed database. Cluster membership is communicated using a Gossip Protocol and manages data integrity using Vector Clocks, where the current state of the cluster is gossiped randomly through the cluster. Joining a cluster is initiated by specifying a set of seed nodes with which to begin gossiping.

Support for Grouping a Cluster into Multiple Roles

Not all nodes of a cluster need to perform the same function: there might be one sub-set which runs the web front-end, one which runs the data access layer and one for the number-crunching. Deployment of actors—for example by cluster-aware routers—can take node roles into account to achieve this distribution of responsibilities.

Leader election

The cluster will, at all times, only have a single leader node. User can subscribe to leadership changes.

Distributed testing framework

We will make our internal testing framework/tool chain, for doing distributed testing, load testing, network failure testing and more, available to our users to allow them to test their own Akka applications (remote or clustered).  

DeathWatch for Remoting

Allow actors to hook into the cluster failure detector and get notified through the regular death watch mechanism.

Clustered Routers

Make the current routers cluster-aware through the use of a ClusterActorRefProvider. Meaning that they should hook in into the cluster membership and be able to use new nodes in the node ring automatically (without hardcoding the actor URL).

Adaptive cluster routers

We will add a number of automatically adaptive routers that base their routing on the runtime statistics of the cluster, e.g. they adapt their the routing policies according to how the application is used:

Pluggable remote transports

In this release we have opened up the remote implementation to support pluggable transports. This means that the user can plug in completely different transports like ZeroMQ or UDP or extend the current transport with encryption like SSL or Kerberos, etc.

Multiple transport support

The remote implementation will support the use of different transports with different actor systems simultaneously. This enables a system to use TCP+SSL to communicate with a remote system, UDP with another, and a completely different transport with a third system.

Performance improvements

Multiple throughput improvements by increasing concurrency in all layers of the remoting.

Akka Rollins

Part I — Akka 2.3

Released on March 5, 2014

Akka Persistence

This release adds a generic API for Event and Command Sourcing. It provides pluggable transaction logging implementations:

Activator Templates

We will migrate all samples and getting started guides into Activator templates, improving them along the way and adding those that we think are currently missing. Everyone is welcome to contribute, of course, be that through complete submissions as well as proposals.

Java 8 Support

Akka 2.3 will contain dedicated or updated APIs to make full use of the new features offered by Java 8, in particular lambdas (i.e. we will provide functional interfaces; see also the specification). The goal is to close the gap between Scala and Java when it comes to the elegance with which actors can be expressed. Existing Java APIs will remain supported as well.

Improvements to Cluster functionality

Up to Akka 2.2 a cluster node which was detected as unreachable cannot come back into the normal reachable state which means that in order to resolve a network partition one side necessarily has to be terminated and restarted. An improvement to the gossip data structures will allow healing a cluster without the need for restarts under certain conditions (i.e. as long as no important messages have been lost or no administrator declared part of the cluster as “down”).

In addition we will work on optimizing gossip protocol and processing to allow clusters with more than the current limit of 200 nodes.