For Akka 2.1 we have reimplemented the Dataflow API to be based on implicit value classes, both to be able to add the API to the Futures that have been moved into the Scala Standard Library, and to keep performance at an acceptable level.
The good news is that the API looks and feels exactly the same as in 2.0.x, so let’s see what Dataflow enables.
As mentioned in our Migration Guide, your beloved Akka Futures transmutated into SIP-14 which is to say that this functionality moved into the scala library itself. But there is more movement:
- The previously contained scala.actors package moves out of the library proper into its own project, and
- Akka actors are bundled with the Scala 2.10 distribution as a replacement.
For Akka users this change does not have visible effects (you will continue to depend on the same artifacts), but for current users of the scala.actors implementation a migration path towards Akka actors is offered. Vojin Jovanovic and Philipp Haller have prepared a comprehensive step-by-step guide to ease this process, which is supported by a migration library offering Akka-like interfaces on top of scala.actors. We’d like to send a big thank you from Uppsala to Lausanne!
In our efforts to make the Akka documentation as good as possible, the 2.1 documentation have now reached a bit over 400 pages. That is a whopping 100 pages more than the 2.0 documentation.
To make this mass of documentation as easily accessible as possible it is now searchable by release directly in the online version. Try it out on the 2.1 Release Candidate Documentation.
Thanks to excellent work by Raymond Roestenburg and Piotr Gabryanczyk the Akka module for Apache Camel is completely rewritten in Akka 2.1.
Camel is an open-source framework based on known Enterprise Integration Patterns and it is great for integrating Akka systems with other external systems. The Akka Camel module provides an easy to use bridge between actors and Camel endpoints.
For Akka 2.1 and Scala 2.10 we have worked together with the Scala communtiy on SIP-14 to bring you a unified standard API for futures in Scala. Since the futures have moved out of Akka and are now part of Scala 2.10 it means that package names and some APIs have changed.
If you are using the Akka Toolkit from Java, then have no fear. The Akka Java API to help you use futures from Java is still there.
This is a brief rundown of the differences. More information is available in the Akka 2.0.x to 2.1.x migration guide
You can now easily use SSL with Akka remoting. It’s simply a matter of configuring it in your
You can read more about SSL and Akka remoting in the Akka remoting docs for Scala or docs for Java. There are also resources available for learning about Java Secure Socket Extension and working with key stores with the Java Keytool.
I’m sure you are all aware of the ongoing efforts spent on the documentation (with no small amount of corrections from our very helpful community), and that you made it your habit to re-read the full 400 or so pages on the second weekend of each month, but still: it is worth pointing out that there are not only additions for all the new features, there are also clarifications. Here are just a few select pointers you could choose to start your next doc journey with:
- looking behind the curtain: the cluster specification
- designing actor systems: blocking with care
- top-level guardians explained
- how to configure multiple actor systems
- a word on dead letters
- supervision and lifecycle clarifications
- Akka use cases
- several updates to the remoting docs, for Java as well as Scala
- status update for durable mailboxes
In the 1.x timeframe we had a second repository called “akka-modules” which was supposed to hold modules which were not considered to be part of the core of Akka, but should still be maintained. This did not work out so well, mostly because developers are lazy and want a single unified build to check their work. Thus we moved some modules into the “akka” project proper and discontinued others (which were not actively enough maintained to make the jump to 2.0). But this left us lacking an incubation area where new modules can mature before being blessed into the core distribution.
This subproject is part of the regular Akka build process, included in the online docs and part of the continuous integration testing. This ensures that the code in there stays up-to-date while Akka evolves. At the same time, this subproject is structured such that individual parts can easily be taken out and incorporated into your own projects, to make use of them and give feedback before we commit to supporting them with all bells and whistles. The idea is that a good module will be championed by external contributors, battle-tested in the field and finally incorporated as a mature member of the Akka family.
The whole setup was tested by implementing a messaging pattern I always wanted to include, but soon after that Kaspar Fischer offered the first candidate: a message throttler. You are welcome to have a look and let yourself be inspired.
With the 2.1 version of Akka we have added scaffolding to help you run and coordinate tests spanning multiple machines. The feature is still experimental but fully functional.
To use the Akka multi node testing in you project you need to add this plugin to your sbt build. In
Your project also needs to have akka-remote-tests-experimental as a dependency. Here is a small sbt build example to get you going. You can put it in
And finally a small multi node test example that demonstrates some barriers and remote communication. Should go into
More information is available in the Akka documentation.