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.
For already completed milestones please refer to the end of this document.
ETA: Jul–Dec 2014
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.
ETA: Feb 2014
This release adds a generic API for Event and Command Sourcing. It provides pluggable transaction logging implementations:
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.
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.
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.
ETA: May–Jun 2014
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:
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.
The gossip protocol will be extended with a naming service holding all a registry with actors in the system and where they currently reside. In order to implement this efficiently the protocol also need to add push-pull gossip to keep the data transferred to a minimum.
The actors in an actor system forms a hierarchical tree. The cluster should be able to, based on user configuration, partition the actor tree at well defined points and distribute the sub-trees out onto the cluster node ring. This will require a new type of dynamic ActorRefs referenceable through a new cluster-aware protocol.
Node death is automatically detected and all actors that were running on the failed node will be automatically migrated to another node in the cluster. All actors that held references to the actors on the failed node will be automatically redirected to the same instances on the new home node. This means that from the client perspective failure recovery is close to transparent.
The details of this milestone will be determined once we have implemented at least the Event Sourcing part of ‘Rollins’. In addition we want to await user feedback to distill out desirable use-cases.
Released on March 6th, 2012
Released on December 23rd, 2012
Released on July 9th, 2013
Implementation is described in detail in the cluster specification.
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.
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.
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.
The cluster will, at all times, only have a single leader node. User can subscribe to leadership changes.
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.
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).
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:
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.
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.
Multiple throughput improvements by increasing concurrency in all layers of the remoting.