Today we shipped Akka.NET v1.0.2, a maintenance release that fixed a number of bugs as well as introduced some exciting new features.
Major Akka.Cluster Stability Upgrades
Akka.Cluster is still in beta at the moment, but we’re on target for a full Akka.Cluster release in Akka.NET v1.1.
In this release we had some new contributors emerge from the ranks of Akka.NET’s production users to deliver some major stability upgrades to Akka.Cluster. We fixed critical issues in the following areas:
- Leader election algorithm;
- Clustered group routers;
- Akka.Remote and Akka.Cluster dispatchers now run on their own dedicated thread pools; and
- Akka.NET scheduler now runs on its own dedicated thread by default.
These changes resulted in massive improvements in cluster stability and reliability for these customers, and has helped put us on track towards our goal of a stable Akka.Cluster release in the near future.
New Akka.Persistence Plugins
If you’re interested in Akka.Persistence, things just became a lot more interesting! In the previous Akka.NET release (v1.0.1) we shipped Akka.Persistence.SQLServer (docs) (NuGet.)
In Akka.NET v1.0.2 we’ve added two new backing stores for Akka.Persistence:
Akka.Persistence is still in beta, but it’s one of the most exciting libraries in Akka.NET due to its ability to add guaranteed delivery and event sourcing to actors with high consistency requirements.
Other New Features
In addition to the above changes, we’ve also added the following additional packages to Akka.NET:
Akka.DI.StructureMap Akka.NET’s dependency injection system now supports StructureMap! You can install Akka.DI.StructureMap via the NuGet commandline:
PM> Install-Package Akka.DI.StructureMap
Akka.TestKit.XUnit2 Akka.NET now has support for XUnit 2.0! You can install Akka.TestKit.XUnit2 via the NuGet commandline:
One of the absolute coolest things you can do in Akka.NET is remotely deploy actors over the internet to other machines. You can literally deploy code somewhere other than the immediate, local process making the call.
And the way this is accomplished is with the Akka.Remote package - it’s the module that adds remoting capabilities to our Akka.NET applications.
When Would I Want to Remotely Deploy an Actor?
There are two common scenarios for when you would want to deploy an actor remotely:
- Work distribution - you need to be able to push work onto remote machines using a remote or clustered router. This is exactly what the Cluster.WebCrawler sample does.
- Accessing machine-specific resources - if you wanted to gather
PerformanceCounter data from an array of remote machines in order to get specific metrics from each machine, remote deployment is an effective tool for accomplishing that.
Outside of these two use cases, it’s far more efficient to contact remote actor systems via
ActorSelection and remote
IActorRefs than it is to work via remote deployments.