My favorite part about teaching Akka.NET to people is the questions I get. I never have any clue what someone is going to ask me, and that’s kind of exciting.

Last Thursday, we had an awesome group of developers participate in our advanced Akka.NET Design Patterns training for half the day. We covered a ton of material, but in that time, there was a basic question that came up:

When should I use an ActorSelection?

I loved this question, because there is more nuance to the seemingly mundane ActorSelection than meets the eye.

When Should I Use An ActorSelection?

The guideline I follow is to use an ActorSelection when:

  1. I need to take advantage of wildcard selection in actor paths for some reason.
  2. I need to communicate with an actor on a remote actor system, and I don’t have an actor reference for it yet.

Wildcard Routing

The first case when I usually use an ActorSelection is when I need to leverage wildcards in my actor paths. This is pretty rare, but one example could be if I needed to distribute a message to a number of actors who all lived at the same level in the hierarchy, or had a well-defined and predictable ActorPath.

For example, let’s imagine I had an OrderActor and needed to report on new orders to finance, marketing, and fulfillment. Let’s imagine that each of those concerns has its own hierarchy, with a NewOrderActor at the second level that is the ingestion point for new orders. It would look like this:

In this case, I could send the new order messages on to all three NewOrderActors with one wildcard ActorSelection, like so:

The release of Akka.NET 1.0 marked the delivery of the project’s first major milestone and enabled us to commit to preserving long-term APIs for the foreseeable future.

The core Akka.NET team and I have put together a rough roadmap that outlines our development priorities for the next 12-18 months. Our chief objective is to build out all of Akka.NET’s high availability (HA) components and release them.

Here’s what the roadmap looks like in release order:

  1. Akka.NET v1.1 - full release of Akka.Cluster
  2. Helios 2.0 & Akka.NET v1.x - add TLS/SSL support to Akka.Remote and improved performance of networked actor systems. Can be released independently of other changes. Learn more about Helios 2.0.
  3. Akka.NET v1.2 - full release of Akka.Persistence with SQL Server, Windows Azure, and filesystem support built in.
  4. Akka.NET v1.3 - full release of Akka.ClusterSharding.
  5. Akka.NET v1.x - add support for Akka.IO, Akka.ClusterClient. Can happen independently of other changes.
  6. Akka.NET v1.4 - release of Akka.Streams and the initial Reactive Streams specification for .NET.

If you’re not sure what the names of these modules refer to then ask in our Gitter chat!

All of these represent major projects that are currently underway on the Akka.NET project itself. These priorities may change as new things occur in the .NET and Akka ecosystems, but for the time being these are the milestones we’ve committed to based on discussions with end-users.

We’re looking forward to having another great year and working with our contributors to deliver more new modules and tools for you to use! So make sure you follow the Akka.NET project on GitHub and get the latest changes!

Today, we’re going to begin introducing the world to the internals of Akka.NET. These are the advanced technical topics and explain what is actually going on “under the hood” to make the magic happen.

We begin our exploration with Akka.Remote.

What Is Akka.remote?

Akka.Remote is one of the most important modules in the entire framework. Akka.Remote is the module which actually enables a big percentage of the awesome feature of Akka.NET, such as:

  • location transparency (not having to care which process—local or remote—an actor lives in)
  • ability to scale out via configuration, instead of code
  • Akka.Cluster and highly-available clustered systems (built on top of Akka.Cluster)
  • ability to remotely deploy actors from one machine to another

In short: understanding Akka.Remote is a powerful tool to have at your disposal for building distributed systems in Akka.NET.

Akka.NET Remote Connections Explained

The most important piece to understand about Akka.Remote is how remote connections work, and what is the topology of actors responsible for managing remote connections.