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: end of 2015
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.
Released on Sep 30, 2015
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.
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
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).
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).
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:
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.
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.
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.
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).
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.
Released on March 5, 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.