In an effort to reinforce my personal learning and summarize the wonderful Akka.NET bootcamp that is provided by Petabridge, I am going to cover each unit in the series as I go through it. I will continue to edit the page if the information is incorrect or not available. Since the topics can be complex, I will provide a TL;DR at the bottom and sources for people who are interested in learning more. So let's get right into it!
Unit 1.1 - How to create your own ActorSystem and actors
What is the Actor model?
- In an actor model, everything is an actor (similar to OOP) and each actor does one task
- Actors communicate via messages and message passing is asynchronous and immutable
- Actors pass the message to ActorReferences, not directly to actors. The ActorReferences take the messages and place them in a mailbox (Queue data structure meaning FIFO) and pushes the messages to OnReceive() when the actor is ready to process them.
One of the guarantees of actors in Akka.NET is that an actor's context and internal state are always thread-safe when processing messages. This is because the messages are immutable and processed serially.
Actors can have an internal state which means when an actor is destroyed or restarted, the actor instance is lost and a new instance is created via Props. This is important to know because an Actor's Life Cycle can be rebooted whenever a problem is encountered:
In the event an Exception is thrown, the actor's mailbox is retained and processed with the new actor instance.
Every Actor has a Parent and Children
An actor has to be created by another actor. This is important because an actor is restarted by it's parent (the terminology is Supervisor). Every parent comes with a default SuperviserStrategy object (but a user can define it's own strategy) that decides to either restart, stop or escalate to the grandparent actor. With a restart, all the children of the parent will be restarted as well.
TL;DR
Concurrency and Location Transparency.
Since actors are lazy, cheap and single tasked, they can easily be scaled so even though you have one message per actor, you can have 10,000 actors -> 10,000 messages occurring at once. Due to messages being immutable and running asynchronously, this is really powerful.
Top comments (0)