Building Concurrent Applications with the Actor Model in Akka.NET

Easily build concurrent .NET applications using the high level abstractions of the Actor Model that automatically recovers from errors and that can be distributed across multiple computers with little additional effort.
Course info
Rating
(350)
Level
Beginner
Updated
Aug 5, 2015
Duration
3h 23m
Table of contents
Introducing Actor Models and Akka.NET
Defining and Using Actors and Messages
Understanding Actor Lifecycles and States
Creating Actor Hierarchies and Isolating Faults
Deploying and Messaging Remote Actors
Description
Course info
Rating
(350)
Level
Beginner
Updated
Aug 5, 2015
Duration
3h 23m
Description

Building concurrent applications is hard, even more so when they need to be scaled up by adding more CPUs or scaled out over multiple computers. By the end of this course, you’ll understand how Actor Models provide a higher level abstraction for building concurrent applications and how to leverage the open source Akka.NET framework to easily build concurrent, self-healing, and distributed .NET applications.

About the author
About the author

With over 15 years experience, Jason Roberts is a Microsoft .NET MVP, freelance developer, and author.

More from the author
Working with Files and Streams in C#
Intermediate
3h 13m
Oct 12, 2018
Error Handling in C# with Exceptions
Intermediate
1h 37m
Aug 6, 2018
More courses by Jason Roberts
Section Introduction Transcripts
Section Introduction Transcripts

Defining and Using Actors and Messages
In the last module we got an overview of actors and messages. In this module, we're going to dig into more detail and see how we can both define and use actors and messages. So in this module, we're going to start off by seeing how we can define actors and some of the good practices to follow when we're doing so. We'll learn about actor references and the fact that we don't have direct references to actors when we sent them messages. We, instead, use the level of indirection of actor references. We'll learn how we define custom messages and some of the good practices to bear in mind when doing so. And then we'll see how we actually go about creating an instance of our actor. And when we do so, we use something called Props, which acts like a recipe for the creation for our actor instance. Finally, we'll see how we can configure our actors to respond to both simple messages such as strings our ints, or instances, of our custom message classes.

Understanding Actor Lifecycles and States
Hi, welcome back. In this module, we're going to learn more about actor lifecycles, and also how we can store and represent states within our actor. So in this module, we're going to kick off by looking at the actor instance lifecycle phases. So an actor can go through a number of different phases during its lifecycle. An actor will eventually be terminated, but it may have been restarted a number of times before it gets to this terminated state. As part of the actor instance lifecycle, there are a number of methods that we can override from the base class that lets us add our own additional custom code during specific parts of this lifecycle. So in this module we'll learn how we can override these methods and add or encode; we'll learn what happens when actor instances terminate; and also, what happens if those actor instances have children of their own. We'll learn some of the different ways an actor can be told to stop, including the sending of a special message type called PoisonPill. Finally, we'll learn about a powerful feature of actors in that they can switch their behavior at runtime. We can define multiple behaviors within our actor and switch between these behaviors based on messages we receive.

Creating Actor Hierarchies and Isolating Faults
Imagine the scene. It's 2:00 a. m. on a freezing winter's night and you're tucked up in a nice, soft, warm bed. Then you're abruptly awoken from a dream of you lying on a palm-covered beach by the all-too-familiar ring of your work mobile phone. The system has crashed again and you need to head into the office to resolve the problem. One of the key features of actor systems is their ability to self-heal. Rather than you having to venture out on snow-covered roads to fix a broken system, the system can instead fix itself. In this module, we're going to learn how to implement this self-healing behavior. So in this module, we're going to be creating our full actor hierarchy for our movie streaming actor system. As part of the creation of our actor hierarchy, we're going to learn that Akka. NET provides a number of high-level system actors for us. When we create actors below these, we create what's called top-level actors. Next, we're going to learn how to send messages to other actors in the actor system if we don't have an actor reference to them. To do this, we're going to learn about actor paths and how we can use actor selections. We'll learn what happens if a child actor fails and how the default parental supervision strategy will cause the child to restart. Finally, we'll learn how we can create our own custom parental supervision strategy that performs different operations on the child depending on the type of exception that's being thrown from the child.

Deploying and Messaging Remote Actors
Distributing an application over multiple computers or processes can often be a difficult thing to configure. With Akka. NET we can easily configure where we want our actors deploying. We don't even need to change any actor code to make this possible, we can simply handle it through configuration. This enables great flexibility in actually deploying our applications without needing major code rewrites. So, in this module we're going to start off by getting an overview of how remote actors work and also the fact that we can remotely deploy actors from one actor system to another. We're going to see how we can use a special configuration language in Akka. NET called HOCON and how this configuration language is human friendly. We'll jump into some demos and we'll go and add a second remote actor system to our solution, so we'll go and add a second console application that's going to host its own actor system instance. In the final demo, we'll go and create some HOCON configuration to actually cause some of our actors to be remotely deployed to another actor system and we'll see how when we do this we don't have to change any actor code.