Type-safety for Akka Actors, better stability for Akka Cluster, and improved serialization

The Akka team at Lightbend and overall Akka community are delighted to announce the immediate availability of Akka 2.6. As Akka is at the core of Lightbend Platform, this Q/A post covers six questions that Java and Scala architects and developers should read to get an idea of what major features went into the release, which optimizations and bug fixes were added, and what other Lightbend technologies benefit from the features in Akka 2.6. As always, you can get started with the latest version on the Akka website here: https://akka.io/docs/

Q: What are the major improvements to enjoy in Akka 2.6?

There are many things to include, and the top 3 highlights we chose are:

  • Akka Typed: In Akka 2.6, we have finally marked the new typed Actor API ("Akka Typed") as stable. In the typed API, each actor needs to declare which message type it is able to handle and the type system enforces that only messages of this type can be sent to the actor.
  • Artery: Artery TCP is the new default transport for actor messaging. It is built on top of Akka Streams TCP and has support for TLS. Artery improves stability for systems using Akka Cluster and also features better performance.
  • Serialization: A new serializer that is using Jackson is included in Akka 2.6, which supports both JSON and binary CBOR formats.

Q: If you had to pick the most significant update in this release, what would it be?

We have to say that this is Akka Typed, the new version of Akka Actors, so to speak.

In Akka, messages are sent via a location transparent handle to the actor, called an ActorRef. It’s this ActorRef in Akka Typed that has a message type parameter, as well as the corresponding type in the behavior of the actor. This means that, unlike in the past, you can now only send messages that are part of that actor’s defined message protocol, and the compiler will help with catching mistakes early. The message protocol becomes very explicit and can also describe interactions by passing typed ActorRefs in the messages, for example describing what response message you can expect. In the end it gives all the benefits that we are used to from strongly typed programs. To see how this looks like in code you can find a Hello World example in the documentation.

While introducing these new APIs, we took the opportunity to rework and improve the usability experience of all main modules, such Akka Persistence and Cluster Sharding. The goal was to make them more guided for the most common usage without limiting the flexibility to go beyond that.

Ultimately, this makes the Akka Typed APIs more approachable, more guided, and provides a better experience by, for example, catching mistakes early when writing the program. This goes further in helping teams try to understand what the system does later on; namely, understanding interactions between actors. This is especially helpful when revisiting old code, investigating a bug, or when trying to navigate and understand code written by someone else. Notably, refactoring in a safe way also becomes much easier.

To get started with Akka Typed we recommend the quickstart guides.

Q: What was the biggest challenge for the folks working on this release?

API design is always challenging; naming is hard, as we know, but we also needed to consider different kinds of target users and many subjective opinions about moving forward. There have been many iterations to come up with the new APIs.

It’s a good time to mention that the classic APIs are still fully supported and existing applications can continue to use the classic APIs, but for new projects we recommend using the new Akka Typed API. It is currently not planned to deprecate or remove the classic API, and it’s also possible to use the new Actor APIs together with classic actors in the same ActorSystem. This means you can introduce Akka Typed for new functionality, or migrate at your own pace, and we hope you like the end result as much as we do :-)

Q: What was the most significant bug fix that it feels good to have finally squashed?

Switching to Artery as transport for actor messaging is very nice to get off our backs. This is a major performance improvement and solves issues that have not been possible to fix in classic remoting. For example, Akka Cluster heartbeat messages and internal system messages are now sent over a different channel than application-level messages, which creates better isolation and stability.

In terms of isolation, Akka internal actors and tasks are now running on a separate dispatcher instead of sharing the default dispatcher with application-level actors. This should improve overall stability and reduce the risk of thread starvation problems. For example, Akka Cluster itself is implemented with actors and those should run undisturbed even if application-level actors are blocking all threads in the default thread pool.

Q: What other Lightbend technologies does this release influence?

This release influences several other Lightbend technologies:

  • The next releases of Play Framework and Lagom Framework will be built on Akka 2.6.0, so stay tuned for those releases soon.
  • Lightbend Telemetry has been updated for Akka 2.6 and Akka Typed, for example including metrics for EventSourcedBehavior
  • Akka Enhancements, Akka HTTP, Akka Management and many other libraries will continue to work with both Akka 2.5 and 2.6.
  • As with recent Akka 2.5.x releases, Akka 2.6 supports the latest Scala version (2.13) and LTS Java version (11), as well as the earlier Scala 2.12 and Java 8 versions.

Q: What does the future roadmap look like for the next release, how can folks contribute?

With Akka 2.6 providing a new stable foundation for the Akka ecosystem as well at Lightbend Platform, the team plans to turn their attention to some of the other satellite projects. Next up are:

  • Version 1.0 of Akka Persistence plugin for Cassandra
  • New minor version 10.2.0 of Akka HTTP
  • Stable and supported APIs of Akka gRPC 1.0
  • Further improvements to Telemetry and system wide observability

In the issue tracker over at GitHub we label issues that would be easy to get started contributing with “good first issue” or “help wanted”. Digging in to other issues in the tracker is of course welcome as well. Unless the task is very simple it can be good to discuss it a bit with the team in the issue or on the akka/dev gitter channel before digging in. We hope to see you there!


For Serious Enterprises…

Want to see Akka in action? Schedule a demo to see what Akka Actors, Akka Cluster, Akka Streams, and more look like in production, featuring observability and metrics provided by Lightbend Console and Lightbend Telemetry.

SCHEDULE A DEMO

Share



Comments


View All Posts or Filter By Tag


Questions?