In addition to Akka.NET joining the .NET Foundation and announcing our participation in the .NET Foundation Summer Hackfest, we had two more major Akka.NET developments to announce on Friday:

• Akka.NET v1.3, which adds .NET Standard support to Akka.NET, is released and now available on NuGet and
• The official Akka.NET website has been totally redone in DocFx in order to make it more readable, user-friendly, and well-organized.

Akka.NET v1.3 has been a work in progress since .NET Core was first released last year and is the culmination of hundreds of commits by dozens of contributors. You can read the official Akka.NET v1.3 release notes here, but what follows are my notes on some of the changes end-users can expect when adopting v1.3 and upgrading from earlier versions of Akka.NET.

.NET Standard 1.6 Support for Akka.NET

The most-requested feature for Akka.NET over the past year has been .NET Standard / .NET Core support.

In case you’re not sure what the difference is between .NET Standard and .NET Core: .NET Standard is a compilation target shared by both the full .NET framework (4.6.*) and .NET Core. Any library that targets .NET Standard 1.6, for instance, can be used inside .NET 4.6.1 AND .NET Core 1.1 applications. You can read more about .NET Standard and the various versions of it here at Microsoft’s official documentation.

Akka.NET’s NuGet packages now target both .NET 4.5 (which we always have, historically) and .NET Standard 1.6. NuGet will automatically install the .NET Standard 1.6 version of the NuGet package if you’re targeting .NET 4.6.1 or .NET Core.

We’ve already been using the Akka.NET v1.3 nightly builds in a new production-facing project and the results have been excellent thus far and we look forward to sharing more details on that experience when we get closer to shipping that project.

Akka.NET Plugins

The next part of the release process for Akka.NET following the adoption of .NET Standard upgrading each of our plugins to support .NET Standard as well. In some cases this may mean having to upgrade the versions of the serializers, logging frameworks, DI containers, and database drivers these plugins depend along the way. These upgrades might cause some disruption in some cases, but that’s part of the price for supporting .NET Core ultimately.

One plugin worth noting in particular: the latest version of the Akka.TestKit.XUnit2 package is currently released in beta rather than its normal RTM status. This is due to XUnit 2.3 itself still being in a beta stage. As soon as that dependency is updated we’ll be able to re-release the Akka.TestKit.XUnit2 package as a stable release again.

Wire Compatibility

Two important things worth noting about Akka.NET v1.3’s wire compatibility:

1. The .NET Core and .NET Full 4.* versions of Akka.NET are not wire compatible with each other, meaning you can’t run a cluster that is half .NET Core and half .NET 4.6.1. The reason for this is that the namespaces for primitive types have changed or been moved under .NET Core, thus serializing messages between the two using the default JSON.NET serializer or Hyperion won’t be feasible without some sort of lookup table for matching primitive type names across different versions of the runtime. We’ve implemented a sample lookup-table adapter to the current JSON.NET serializer in this pull request which can be used to make cross-platform communication possible between Akka.NET on .NET Core and on the full .NET framework, but we have no plans to merge it into the code base any time soon due to the performance overhead it would incur. If you really need to be able to run a hybrid .NET / .NET Core cluster, consider defining all of your messages using a cross-platform interchange format like Google Protocol Buffers or MsgPack instead of relying on a polymorphic serializer.
2. Akka.NET v1.3 is not wire-compatible with Akka.NET v1.2. Part of the cost of supporting .NET Standard meant having to upgrade some of our dependencies and in this case we had to upgrade from Google Protobuf2 to Protobuf3, which are not backwards-compatible. In addition to that change all built-in Akka.NET messages are now serialized on Akka.Remote via built-in protobuf serializers instead of relying on Hyperion or JSON.NET. This is change was made in order to better-align with the JVM implementation of Akka.NET but also to help improve version tolerance on all built-in messages as well over time.

Akka.Persistence

After years of being in beta status, Akka.Persistence is now released from beta and is considered to be a stable module. There will, however, be some coming changes to the Akka.Persistence ecosystem:

1. The BatchingJournal inside Akka.Persistence.Sql.* is still considered to be experimental at this stage, although users are free to enable it inside their applications;
2. The PeristenceFsm base class is now available, which will allow you to build full-blown finite state machines with persistent capabilities;
3. Each Akka.Persistence plugin is going to have its own serialization system designed to help it take full advantage of all of the local capabilities of each database. For instance, Redis and MongoDb will be using JSON serialization since that’s a natural format for representing objects on each of those platforms; and
4. All of the officially supported Akka.Persistence plugins will be updated to support .NET Standard 1.6.

Other Major Updates

In addition to the major line items above, we’ve made other changes to some of our other modules as well.

Akka.Cluster.Sharding Updates

Next on our radar for promotion to a stable release is Akka.Cluster.Sharding. As of v1.3.0 Cluster.Sharding is still in beta; however, we’ve made numerous improvements to it including serialization fixes, major bug fixes, serialization improvements, and fully enabling the entire Akka.Cluster.Sharding multi-node test suite. We encourage you to try it and see how it compares to before - you should notice major improvements.

Akka.IO Rewrite

Akka.IO’s internals have been completely rewritten to use SocketAsyncEventArgs and fully asynchronous I/O inside Akka.NET. In addition, Akka.IO makes clever use of buffer pooling and other techniques designed to help achieve high throughput with still relatively low memory footprint costs.

To give you a sense of how well Akka.IO now performs, here are some numbers for comparison:

Server	Avg. msg/sec	Baseline
DotNetty	40215,1	1.0
Akka.Streams.IO (.NET)	36983,65	0.92
Akka.Streams.IO (JVM)	37560	0.93

As for the Akka.IO APIs: some of the public APIs related to working with ByteString have been removed or modified, but it’s nothing earth-shattering. We were able to upgrade Petabridge.Cmd to the new Akka.IO APIs in about 30 minutes.

Akka.Remote Performance Improvements

One area of tremendous importance to the Akka.NET team was launching on .NET Core with our best foot forward with respect to Akka.Remote performance, and we’re confident that we’ve done that. The performance of Akka.Remote on Akka.NET v1.3 is on average 36% faster than it was in Akka.NET 1.2.3 and we are going to continue increasing that figure even higher with the subsequent updates we have planned for Akka.NET 1.3.* and beyond.

If you’re interested in learning more about the full set of changes in Akka.NET 1.3, we recommend that you take a look at the issues list linked via the official Akka.NET v1.3 release notes here.

And as a final thought: “thank you” to all of the contributors who submitted patches, the end-users who reported bugs, and all of the Akka.NET champions who helped get it adopted in their workplaces and projects. You’ve all helped make the Akka.NET the growing rocket ship of a project that it is today and we couldn’t be more grateful for it.

If you liked this post, you can share it with your followers or follow us on Twitter!