Akka is a modern event-driven middleware framework, for building high performance and reliable distributed applications in Java and Scala. Akka decouples business logic from low-level mechanisms such as threads and locks. Your Scala or Java program logic lives in lightweight actor objects which send and receive messages. With Akka, you can easily configure how actors are created, destroyed, scheduled, and restarted upon failure.
What does it mean to you? By building with Akka, you gain the ability to reliably scale your application to efficiently run on modern multicore hardware, and to span multiple nodes in a datacenter or cloud service provider, without constantly needing to reinvent the wheel.
Akka 2.0 represents a major update to the Akka 1.x series of releases. The stats are impressive: 700 tickets closed and 1,020 files changed with 98,683 insertion and 57,415 deletions, and over 300 pages of reference documentation. While many of the key concepts in 2.0 will be familiar to Akka 1.x developers, there there are quite a few changes under the hood. So we’ve provided a migration kit to ease the transition (more on this below).
We’ve already highlighted some of the new notable features when we announced the Akka 2.0 pre-release milestones. In this post, we’ll give a broader overview of what’s in the Akka 2.0 final release.
APIs for both Scala and Java
We at Typesafe of course love Scala, but being able to effectively use our frameworks from Java (or in fact from any other JVM language) is critical for us. That’s why with Akka 2.0, we continue to provide two, equally polished sets of APIs: one for Scala and one for Java developers. That means you can have access to all the functionality in Akka without writing a single line of Scala code.
One of the new building blocks of akka applications is the Actor System. You can think of actor systems as standalone containers that allow users to manage the behavior, structure, life-cycle, configuration, logging of certain actors separately from each other. Actor systems make it easier to structure and manage your application.
Supervision and Death Watch
Two key aspects that can be configured in actor systems are actor supervision and monitoring (the chillingly-named Death Watch).
Supervision describes a dependency relationship between actors, where the supervisor delegates tasks to subordinates while managing their failures. Monitoring, on the other hand, is used to tie one actor to another so that it may react to the other actor’s termination, in contrast to supervision which reacts to failure.
While supervision was available in a limited form in earlier versions of Akka, in 2.0 we have introduced:
Paths and Addresses
But how can you distinguish between the various actors managed by a supervisor? That's where actor paths and addresses come in. Since actors are created in a strictly hierarchical fashion, there must exist a unique sequence of actor names that help the supervisor to identify actors. One way to envision the aforementioned unique sequence is to think about a file system. Indeed, that was the reason why Akka adopted the name “path” to refer to it. You can also query for, retrieve and send messages to an ActorSelection consisting of a group of actors.
With every actor identified by a URI—with remote protocol, host, port and path—it becomes very easy to refer to actors across node boundaries, essentially removing the formal distinction between local and remote actors. The implementation of actor supervision has been simplified so that it works the same whether parent and child are on the same or different nodes. And since this distributed approach lends itself so well to scaling out, we made it even easier by allowing the deployment of actors to be specified purely by configuration, instead of through APIs as was the case in Akka 1.x. This means you can adjust the topology of your application at deployment time, without modifying the source code itself.
With Akka 2.0, we’ve also made it easier to send messages to groups of actors. The new Event Bus feature brings a set of composable traits which should help you to build event driven, publish/subscribe style systems much more easily than before.
Improvements to Akka Futures
This leads us to the changes around akka.dispatch.Future. With Akka 2.0, Futures are decoupled from their ExecutionContext, Timeoutmanagement and Actor.ask functionality. This is great news since these changes not only make akka.dispatch.Future more adherent to the the Single Responsibility Principle, but also allow much more flexibility when it comes to designing non-blocking concurrent computations with actors and futures. It’s also worth mentioning that Akka 2.0 is using the upcoming Scala 2.10 standard library Future implementation, which is a joint effort between the EPFL Scala team and the Akka team. Look out for scala.concurrent.future!
Much Improved Performance and Scalability
Akka 2.0 now uses a new Fork/Join executor (developed by Doug Lea) to improve message passing throughput and scalability. Ourbenchmarks show that on multi-core machines the improvements can be as high as 10X compared tojava.util.concurrent.ThreadPoolExecutor.
Finally, the new version of Akka comes with a migration kit that should make it easier for 1.x users to migrate in small, incremental steps (you can learn about this feature here).
Of course these are just the highlights; there are many other changes and improvements, like the redesigned Routers and Dispatchers, for example. We hope this short introduction got you excited enough about Akka 2.0 to dig in and discover the rest!
You can find out more about Akka 2.0 by browsing the extensive and newly expanded documentation on the Akka project site. The open source release is available for download at the freshly redesigned Akka project site.
Of course, Akka 2.0 will also plays a central role in the commercially supported Typesafe Stack 2.0.