Introduction to Akka Actors

  • an actor encapsulates its state and part of the application logic
  • actors interact only through asynchronous messages and never through direct method calls
  • each actor has a unique address and a mailbox in which other actors can deliver messages
  • the actor will process all the messages in the mailbox in sequential order (the default implementation of the mailbox being a FIFO queue)
  • the actor system is organized in a tree-like hierarchy
  • an actor can create other actors, can send messages to any other actor and stop itself or any actor is has created.
  1. State: Actor objects will typically contain some variables which reflect possible states the actor may be in. This can be an explicit state machine or it could be a counter, set of listeners, pending requests, etc. These data are what make an actor valuable, and they must be protected from corruption by other actors. Akka actors conceptually each have their own light-weight thread, which is completely shielded from the rest of the system. This means that instead of having to synchronize access using locks you can just write your actor code without worrying about concurrency at all. Behind the scenes Akka will run sets of actors on sets of real threads, where typically many actors share one thread, and subsequent invocations of one actor may end up being processed on different threads.
  • class SummingActor extends Actor {
    // state inside the actor
    var sum = 0
    // behaviour which is applied on the state
    override def receive: Receive = {
    // receives message an integer
    case x: Int => sum = sum + x
    println(s”my state as sum is $sum”)
    // receives default message
    case _ => println(“I don’t know what
    are you talking about”)
    }
    }

Actor Hierarchy

An actor in Akka always belongs to a parent. Typically, you create an actor by calling context.actorOf(). Rather than creating a “freestanding” actor, this injects the new actor as a child into an already existing tree: the creator actor becomes the parent of the newly created child actor.

Hierarchy
  • / the so-called root guardian. This is the parent of all actors in the system, and the last one to stop when the system itself is terminated.
  • /user the guardian. This is the parent actor for all user created actors. Every actor you create using the Akka library will have the constant path /user/ prepended to it.
  • /system the system guardian.

ActorSystem

In Akka, an ActorSystem is the starting point of any Akka application that we write.

Actor Communication

Actors have methods to communicate with each other actors like tell (!) or ask (?) where the first one is fire and forget and the second returns a Future which means the response will come from that actor in the future.

Forward

Forwarding messages is similar to “tell”-ing messages with a subtle difference — a “forward” does not modify the sender of the messages. If a message is sent from A->B->C actor then If we use forward then for C sender will B but if we use tell then sender will come as A.

Dispatchers and executors

The dispatcher in your actor system is responsible for assigning a thread to an actor instance so that it can do work. When an actor instance has no messages to process, it just sits there idle, not taking up any threads. This is why it’s okay to have so many actor instances within your system at once (as long as they are not all trying to do work all the time). They don’t take any resources, aside from a small amount of heap memory, unless they are processing a message.

Simple Hello World Application

import akka.actor.Actorimport akka.actor.ActorSystemimport akka.actor.Propsclass HelloActor extends Actor {def receive = {case "hello" => println("hello back at you")  case _    => println("huh?")}}object Main extends App {val system = ActorSystem("HelloSystem")// default Actor constructorval helloActor = system.actorOf(Props[HelloActor], name = "helloactor")helloActor ! "hello"}
  • Import all the Akka actor classes you need.
  • Define an Actor, defining behavior in the special “receive” method.
  • Create a “main” object where you can test things.
  • You need an ActorSystem to get things started, so create one, with an arbitrary string.
  • You create an Actor instance with actorOf, and that line shows the syntax for an Actor whose default constructor takes no arguments.
  • Now that we have an instance of an actor, we send messages.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store