Stopping an actor is a routine operation that developers often find confusing. This is because each actor is like a micro process, and all interaction with an actor is asynchronous. So shutting down an actor is more complex than stopping entities in procedural code.

In this post, I’m going to review one of the common questions that I’ve heard lately:

How do I stop an actor?!

The Ways of Stopping an Actor

In short, there are three ways to stop an actor:

  1. Stop() the actor: stops the actor immediately after it finishes processing the current message.
  2. Kill the actor: this throws an ActorKilledException which will be logged and handled. The actor will stop immediately after it finishes processing the current message.
  3. Send the actor a PoisonPill: the actor will finish processing the messages currently in its mailbox, and then Stop.

Now let’s go over each in detail.

1) The Default: Stop() an Actor

This is the go-to method to stop an actor, and should be your default approach.

What Happens When I Stop() an Actor?

This is the sequence of events when you Stop() an actor:

  1. Actor receives the Stop message and suspends the actor’s Mailbox.
  2. Actor tells all its children to Stop. Stop messages propagate down the hierarchy below the actor.
  3. Actor waits for all children to stop.
  4. Actor calls PostStop lifecycle hook method for resource cleanup.
  5. Actor shuts down.

The point of this sequence is to make sure that an actor—and any hierarchy beneath it—have a clean shut down.

How Do I Use Stop()?

You Stop() an actor via the ActorContext, like this:

// targetActorRef dies immediately after...

The actor model is a radically new concept for the majority of Akka.NET users, and therein lies some challenges. In this post we’re going to outline some of the common mistakes we see from beginners all the time when we take Akka.NET questions in Gitter chat, StackOverflow, and in our emails.

7. Making message classes mutable

One of the fundamental principles of designing actor-based systems is to make 100% of all message classes immutable, meaning that once you allocate an instance of that object its state can never be modified again.

The reason why immutable messages are crucial is because you can send the same message to 1000 actors concurrently and if each one of those actors makes a modification to the state of the message, all of those state changes are local to each actor.

There are no side effects to other actors when one actor modifies a message, which is why you should never need to use a lock inside an actor!

For example, this is an immutable message class:

public class Foo{ public Foo(string name, ReadOnlyList<int> points){ Name = name; Points = points; } public string Name {get; private set;} public ReadOnlyList<int> Points {get; private set;} } 

This class is immutable because:

  • string is an immutable class - any modifications to it produce an entirely new string. The original is never modified, so to all of the other actors processing this Foo instance

Lots of folks have been asking about Akka.NET and ASP.NET MVC integration on StackOverflow and in our Gitter chat room, so we thought it was time we created the definitive post on how to integrate these two amazing technologies together.

Note: Everything in this article also applies to Web API, Nancy, WCF, and ASP.NET WebForms.

Use Cases

So when would you want to use Akka.NET and a web framework like ASP.NET together at the same time?

Well, you might be like Joel in our “Akka.NET Goes to Wall Street” case study and need to manage concurrent reads / writes to a shared object model.

If you’re building anything resembling a chat room, web-based game, collaboration software, and more - then congratulations: managing concurrent mutations to shared state is something you’re going to have to do. Akka.NET actors are a tremendously better option than sprinkling your code with locks.

In general, what most people use Akka.NET for in the context of ASP.NET is to communicate with others network services the ASP.NET app might depend on, such as remote Windows Services via Akka.Remote and Akka.Cluster. This is especially useful if you need to do any sort of stateful web application programming, but that’s a story for a different day.

How to Start an ActorSystem in ASP.NET

If you’ve gone through Akka.NET Bootcamp, and you should if you haven’t yet, you know how to start an ActorSystem:

// config automatically loads from App.config / Web.config var actorSystem = ActorSystem.Create("myactorsystem"); var someActor = actorSystem.ActorOf(Props.Create(() => new FooActor()));...