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
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:
PM> Install-Package Akka.TestKit.XUnit2...
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
PerformanceCounterdata 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.
I have to level with you. Dealing with network programming in my applications has always freaked me out a little bit.
You know what I’m talking about, don’t you?
Let’s be real about it: low-level network programming is some scary shit. When you have to step beyond the nice client libraries that wrap the networking protocols, there are sharp edges that can gleefully poke you in the eye whenever you make the tiniest misstep in your code.
To put it lightly, low-level network programming has not been a very pleasant experience.
There’s Power Beyond The Pain
And yet… it’s CRAZY powerful. It’s the key to the kind of applications you want to be building in your future.
Want to create a serverless, peer-to-peer, multiplayer video game? Get ready to dive into the networking stack.
Want to build a realtime analytics system for a network of remote devices in the Internet of Things? Yeah, request/response ain’t gonna cut it.
What about creating a live trading or marketing automation system with single-digit-millisecond response times? Ciao, HTTP. It’s been fun while it lasted.
Most developers I know are THRILLED by the idea of working on applications like this. And yet for most, building applications like this seems out of reach. Somehow off the table.
WTF? What’s up with that?
An HTTP Too Far?
It’s actually very simple. The reason that bold ideas like this seem out of reach is because most of us have been conditioned to use HTTP for…wait for it…everything.