Akka 2.1.2 Released
Dear hAkkers,
We—the Akka committers—are pleased to be able to announce the availability of Akka 2.1.2. This is the second maintenance release of the 2.1 branch, where the main changes are that it was built and tested against Scala 2.10.1 and that it comes with true Javadoc generated by the GenJavaDoc plugin.
This release is backwards binary compatible with version 2.1.0, and 2.1.1, which means that the new JARs are a drop-in replacement for the old ones (but not the other way around). Always make sure to use at least the latest version required by any of your project’s dependencies.
Known Issues
Due to the restriction imposed by binary compatibility—which is kept for the patch releases within a minor release such as 2.1.x—not all known issues can be fixed. The currently known issues in the 2.1.x series are:
- ActorSystem.shutdown() does not terminate all threads if akka.remote.netty.use-dispatcher-for-io is set to true
Migrating from Older Releases
When migrating an existing project from Akka 2.0.x please have a look at our migration guide
When migrating from the Akka 1.3.x series please follow first the migration guide towards version 2.0.5
About the Cluster Support
The “akka-cluster” module is published under the name “akka-cluster-experimental” to emphasize that its status is not yet final. This denomination is not due to sub-par standard of the module; the cluster support has been tested thoroughly and it works as documented. The reason for the “experimental” tag is that this rather important module is now presented to the general public for the first time, and although we have received valuable feedback from early adopters we anticipate possible API changes in order to meet all of your requirements. Work is continuing on Akka’s cluster support, and we will formally declare it officially supported and stable with the next major release—Akka 2.2 ‘Coltrane’. Please help us make it the best possible solution by continuing to give feedback on the mailing list and telling us what can be improved.
IMPORTANT NOTICE
The artifacts comprising this release candidate have been published to https://oss.sonatype.org/content/repositories/releases/ and also to Maven Central. In addition, we adopted the SBT standard of encoding the Scala binary version in the artifact name, i.e. the core actor package’s artifactId is “akka-actor_2.10”.
2.1.2 compared to 2.1.1:
* 5 tickets closed
* 49 files changed, 361 insertions(+), 287 deletions(-)
* … and a total of 3 committers!
Fixed Tickets: see the assembla milestone
Happy hAkking!
Release Status Update for Akka 2.2 “Coltrane”
Dear hAkkers,
the end of the first quarter of 2013 is drawing close and many of you are looking forward to the release of “Coltrane” a.k.a. Akka 2.2. The main new feature in this release will be cluster support without the“experimental” tag. We have received some encouraging feedback for the cluster preview shipped withAkka 2.1 and have been developing a few things on top of it ourselves, which has led us to replace and/or polish some parts (the new actor-based remoting comes to mind as well as improving the formulation of the core ActorCell to keep it well-oiled and maintainable) and has also highlighted a few warts which need to be removed. The latter include making the internal parent–child communication reliable in all cases—which means for example changing the way how failure is signaled to the parent—and it also means bringing the life-cycle semantics of local and remote ActorRefs in sync (up to 2.1 a remote ActorRef would look up the current inhabitant of a name on the remote host for each message send, even if that actor terminated int he meantime and a new one was created with the same name).
We also discovered some missing features which would make a lot of sense on the Coltrane milestone, for example the ability to slice a cluster into multiple pieces with different roles, or fixing the message serialization protocol to support interoperability between different versions of Akka in the future. The precise details of how far the latter reaches remain to be determined. We could have placed these features on the next milestone—Rollins—but we felt that they are more urgently needed than the cluster name service.
All in all we have expanded the scope of Coltrane and also spent energy on removing technical debt before it accumulates, which leads to a delay in getting the release out. We will cut a new milestone next Monday which contains some of the aforementioned work, but it will take approximately until the first week of April until we can call Coltrane feature complete. At that point we will release another milestone so all the curious and adventurous among you can try it out in anger, which is also what we will then be doing: in order to deliver the best possible Coltrane release we will concentrate for a few weeks on giving it a thorough beating, writing more tests, running benchmark applications and so on. This will flush out bugs and help us identify and fix remaining usability issues, and we hope that you—our dear and helpful community—will lend a hand with this.
The Second Step: Akka Typed Channels
The previous post described the ground work, getting geared up to employ the power of macros within Akka and doing type calculations. This post focuses on the user-visible features which are enabled by the macro machinery, presenting a new face for actor communication. The untyped “receive” method is replaced by declaration of any number of different input channels (though the single-mailbox principle is kept); the untyped “!” operator is replaced by different ones to avoid confusion.
Akka 2.1.1 Released!
Dear hAkkers,
We—the Akka committers—are pleased to be able to announce the availability of Akka 2.1.1. This is the first maintenance release of the 2.1 branch, which besides documentation updates and the fixes mentioned below also contains a back-port of most of the cluster-related changes in the recently released 2.2-M1.
The issues fixed are:
- release thread pool used by Netty’s ExecutionHandler more timely
- passive remote connections now work when using secure cookies
- do not silently swallow exceptions in ForkJoinPool executor anymore
- fix a bug in HashedWheelTimer which would schedule events incorrectly if delay is multiple of one wheel rotation (thanks Matthew Neeley)
- fix reporting of error condition when IOManager binds to a port
- make sure to set Thread.interrupt() flag when catching InterruptedException during tell()
- Netty does not close the connection anymore upon encountering a non-serializable or too large message
- PinnedDispatcher does not allow its thread to time out anymore, keeping the actor on the same thread (as opposed to only on its own thread)
- actually disallow sending `null` messages (was always forbidden by documentation and only worked on some special ActorRefs)
- StdoutLogger restores stdout-loglevel during system shutdown
- do not leak the default dispatcher anymore
- do not set SO_REUSEADDR for remoting on Windows (which implements this in a buggy way)
- properly log exceptions without a message in JulEventLogger (thanks Sam Halliday)
The changes in the cluster module are:
- cluster metric-aware adaptive load balancing routers
- automatically load cluster extension when used, no need to declare in `akka.extensions` anymore
- fire DeathWatch only upon member DOWN, not already at UNREACHABLE
- allow configuration of minimum number of members before starting the cluster
- cluster singleton pattern
- detect failure even when no heartbeat was ever sent
In addition there have been a great number of documentation updates including a whole new section on terminology.
This release is backwards binary compatible with version 2.1.0, which means that the new JARs are a drop-in replacement for the old ones (but not the other way around). Always make sure to use at least the latest version required by any of your project’s dependencies.
Known Issues
Due to the restriction imposed by binary compatibility—which is kept for the patch releases within a minor release such as 2.1.x—not all known issues can be fixed. The currently known issues in the 2.1.x series are:
- ActorSystem.shutdown() does not terminate all threads if akka.remote.netty.use-dispatcher-for-io is set to true
Migrating from Older Releases
When migrating an existing project from Akka 2.0.x please have a look at our migration guide.
When migrating from the Akka 1.3.x series please follow first the migration guide towards version 2.0.5.
About the Cluster Support
The “akka-cluster” module is published under the name “akka-cluster-experimental” to emphasize that its status is not yet final. This denomination is not due to sub-par standard of the module; the cluster support has been tested thoroughly and it works as documented. The reason for the “experimental” tag is that this rather important module is now presented to the general public for the first time, and although we have received valuable feedback from early adopters we anticipate possible API changes in order to meet all of your requirements. Work is continuing on Akka’s cluster support, and we will formally declare it officially supported and stable with the next major release—Akka 2.2 ‘Coltrane’. Please help us make it the best possible solution by continuing to give feedback on the mailing list and telling us what can be improved.
IMPORTANT NOTICE
The artifacts comprising this release candidate have been published to https://oss.sonatype.org/content/repositories/releases/ and also to Maven Central. In addition, we adopted the SBT standard of encoding the Scala binary version in the artifact name, i.e. the core actor package’s artifactId is “akka-actor_2.10”.
2.1.1compared to 2.1.0:
- 55 tickets closed
- 604 files changed, 8100 insertions(+), 2626 deletions(–)
- … and a total of 8 committers!
Fixed Tickets: see the assembla milestone
Happy hAkking!
2.2-M1 Spotlight: Cluster Singleton Pattern
Using a singleton should not be the first design choice, but for some use cases it is convenient and sometimes also mandatory to ensure that you have exactly one actor of a certain type running somewhere in the cluster.
This can be implemented by subscribing to LeaderChanged events, but there are several corner cases to consider. Therefore, this specific use case is made easily accessible by the Cluster Singleton Pattern in the contrib module.
The singleton actor is always running on the leader member, which is nothing more than the address currently sorted first in the member ring. This can change when adding or removing members. With the names given above the path of singleton actor can be constructed by subscribing to LeaderChanged cluster event and the actor reference is then looked up using actorFor:
Read more in the documentation.
2.2-M1 Spotlight: Startup when Cluster Size Reached
With a configuration option you can define required number of members before the leader changes status of ‘Joining’ members to ‘Up’.
You can defer startup of actors until the cluster has at least the defined number of members.
Read more in the docs for Scala or in the docs for Java.
The New Cluster Metrics-Aware Adaptive Load-Balancing Routers and The Cluster Metrics API
Finally with the release of Akka 2.2-M1, one of the most notable features in Akka Cluster becomes available - metrics-based adaptive cluster-aware routers. While cluster-aware routers have been available since Akka 2.1, the internal cluster metrics API and it’s initial consumer of this valuable data now become usable.
Building on my previous post, Cluster Health, State and Fault Tolerance, now the fun can begin.
2.2-M1 Spotlight: Adaptive Load Balancing Based on Cluster Metrics
The member nodes of the cluster collects system health metrics, such as heap memory and CPU usage. The metrics is spread to other nodes and consumed by a new type of router that performs load balancing of messages to cluster nodes based on the cluster metrics data.
The router is defined in the same way as other routers:
and in this case it’s configured as follows:
Many thanks to Helena Edelson for her great contributions to the metrics design and implementation. In an upcoming blog post she will describe this topic in more detail.
Read more in the docs for Scala or in the docs for docs for Java.
Akka 2.2-M1 Released
- Metrics-based adaptive cluster-aware routers
- DeathWatch fires upon node DOWN (previously on UNREACHABLE)
- Configurable minimum number of nodes before cluster starts
- ClusterSingleton actor pattern
- Hardening of the code by adding stress tests
- various fixes, optimizations
- Smaller SPI for implementing other transport drivers
- Support for multiple transports within one ActorSystem
- No more blocking message sends due to broken connections or during connection establishment
- Currently still using Netty, but will switch to Akka IO soon
- Completely new IO layer written in collaboration with the spray.io team
- Actors all the way down—until you hit NIO
- No external dependencies
- Extreme scalability
- No compromises on the API (i.e. fully exposing the different capabilities of e.g. TCP and UDP)
- Type-safety for message sends which is on par with type checking of method invocations
- Based on Scala 2.10 macros; unfortunately not possible to do in Java
- Very early preview, expect API changes within the next weeks
commits added removed
62 6476 3442 Roland
58 8925 4476 Patrik Nordwall
57 10824 6041 Endre Sándor Varga
43 3040 4311 Viktor Klang
17 819 440 Björn Antonsson
11 1324 322 Johannes Rudolph
10 1109 527 Mathias
6 1108 289 Rich Dougherty
5 311 139 RickLatrine
2 83 20 Kaspar Fischer (hbf)
2 127 66 Christophe Pache
2 163 66 Raymond Roestenburg
1 10 3 Michael Pilquist
1 127 127 drewhk
1 548 77 Helena Edelson
1 38 24 Matthew Neeley
1 8 10 Peter Vlugter
1 3 3 Thomas Lockney
1 36 35 Derek Mahar
Happy hAkking!
Tuning Dispatchers in Akka Applications
One of the biggest questions I encounter among users of Akka is how to use dispatchers to create failure zones and prevent failure in one part of the application from affecting another. This is sometimes called the Bulkhead Pattern. And once I create the failure zones, how do I size the thread pools so that we get the best performance from the least amount of system resources used? The truth is, every application is different, and you must build your system and measure its performance under load to tune it effectively. But here are some tips and tricks.
