Akka — Overview — How stuff works
Self note: In this article I’m going to understand the basic functioning of actors & small introduction to core concepts like actor system, life cycle of an actor, etc.
Let’s try to understand Actor: Actor is a fundamental element of actor system, that wraps state, behavior and it’s child actors. actors are distributed, concurrent in nature. Actor system is a container that inhibits the collaboration of actors and conducting basic required functionalities among actors such as scheduling tasks in the background, tackles communication, providing robust concurrency and reliable distribution, provides powerful control by configurations, and logging, etc…
“Actor” design:
Actor is a combination of state, behavior, child actors, supervision (exception handling) strategy, and a mailbox which contains messages. Note that it will always have mailbox with at least no messages. 1. An actor’s state is formed by possible set of variables denotes whats the current state of actor, can have listeners.. 2. Behavior is nothing but the way we use methods when a particular message received by an actor, in a precise view, the way we match the pattern when some action happened on an actor. 3.And yes it may contain child actors as well. 4. supervisor strategy is the ability to deal with different faults those may occur in real time. A declarative code for fault tolerance is here:
Behaviors.supervise(behavior).onFailure[IllegalStateException](SupervisorStrategy.restart)This example restarts the actor when it fails with an IllegalStateException
5. An actor can enqueue into another actor’s Mailbox or dequeue. vice- versa.
Possibly Actor can have any of the phase as above mentioned in image. Let’s zoom in. So Actor Life cycle methods are:
preStart(): By overriding this method we can decide what should be done after initializations, memory allocations and all other stuff happened.
preRestart(): Typically we can manage the behavior before actor restarted by some reason.
postRestart(): Here we decide what to do when actor restart happens.
postStop(): Provided that, actor’s all instances to it’s children actors might de instantiated before postStop called. It’s just the last thing to deal with actor.
Final words: Actor reduces the head aches in thread management and deals the concurrency parallelly.
Look on Actor Supervision & Strategy
So, why do we need supervision over the custom and system actors?
Suppose an exception came while processing a message from a mailbox, and we would need to handle the way the actor undergoes suspension and what could be done for the message (probably we should retry processing the same). Supervision provides some facilities to solve problems while errors.
one-for-one Supervision: in One-For-One Supervision, whenever an exception gets to the actor it will be the only actor that either could be resumed, stopped or restarted; and of course all actors who handle that message also affect.
all-for-one Supervision: Supervision for the affected actor and all its parallel nodes or actors which has a dependency with the affected actor. Same action will be taken for all dependent actors by the parent actor.
Actor Hierarchy: how failures bubble up in the hierarchy?
Actor Termination
It will be stopped by its supervisor (parent actor), it will free up its resources, draining all remaining messages from its mailbox into the system’s dedicated “dead letter mailbox” which will forward them to the EventStream as Dead Letters
Finally Terminating…
We’ve tried to cover basic stuff — how stuff works. Need to understand the actor system deeply, and how the model compensates for our daily problems to the core. Try to learn new things on this…!
