Code: https://github.com/arild/akka-workshop
- 'java' and 'scala' are starting point for exercises
- 'java-solution' and 'scala-solution' for solution
- E.g. 'git checkout java' for branch with Java exercises
- Start downloading dependencies: './sbt test' or 'mvn test'

Outline

Part 1 - Creating actors and sending messages
Part 2 - Actor supervision and death watch
Part 3 - Routers

What is Akka?

Motivation

Outline

Part 1 - Creating actors and sending messages
Part 2 - Actor supervision and death watch
Part 3 - Routers

The Actor Model

Actors sends messages asynchronously
Actors process messages sequentially

The Actor trait defines only one abstract method, receive, which implements the behavior of the actor.
You need to provide a pattern match for all messages that it can accept and if you want to be able to handle unknown messages then you need to have a default case.
Actors are created by passing a Props instance into the actorOf factory method which is available on ActorSystem and ActorContext.
Props is a configuration class to specify options for the creation of actors, think of it as an immutable and thus freely shareable recipe for creating an actor including associated deployment information.
The call to actorOf returns an instance of ActorRef. This is a handle to the actor instance and the only way to interact with it. The ActorRef is immutable and has a one to one relationship with the Actor it represents. The ActorRef is also serializable and network-aware. This means that you can serialize it, send it over the wire and use it on a remote host and it will still be representing the same Actor on the original node, across the network.

Hello Actor

import akka.actor._

class GreetingActor extends Actor {
  def receive = {
    case message: String => println("Hello " + message)
  }
}

object GreetingActor extends App {
  val system = ActorSystem("MySystem")
  val greetingActor: ActorRef = system.actorOf(Props[GreetingActor])
  greetingActor ! "Hulk Hogan"
}

GreetingActor_1.java|scala

Sending Messages

import akka.actor._

case class SayHello(name: String)

class GreetingActor extends Actor {
  def receive = {
    case hello: SayHello => {
      println("Hello " + hello.name)
      sender ! hello.name
    }
  }
}

object GreetingActor extends App {
  val greetingActor = ActorSystem("MySystem").actorOf(Props[GreetingActor])
  greetingActor ! SayHello("Pope Benedict")
}

GreetingActor_2.java|scala

«self» reference to the ActorRef of the actor
«context» exposes contextual information for the actor and the current message.
The default implementation of Scheduler used by Akka is based on job buckets which are emptied according to a fixed schedule. It does not execute tasks at the exact time, but on every tick, it will run everything that is (over)due.
If you schedule Runnable instances you should be extra careful to not pass or close over unstable references.
If you need to schedule an invocation it is better to use the schedule() variant accepting a message and an ActorRef to schedule a message to self (containing the necessary parameters) and then call the method when the message is received.

Scheduling Work

import akka.actor._
import scala.concurrent.duration._

object DoGreeting

class GreetingActor(delay: FiniteDuration) extends Actor {

  override def preStart() = {
    scheduleNextGreeting()
  }

  def receive = {
    case DoGreeting => {
      println("Hello!")
      scheduleNextGreeting()
    }
  }

  def scheduleNextGreeting() {
    import context.dispatcher
    context.system.scheduler.scheduleOnce(delay, self, DoGreeting)
  }
}

GreetingActor_3.java|scala

Part 1 - Exercises

git clone https://github.com/arild/akka-workshop.git
Implement ComputeActor
Make tests in ComputeActorTest green
Have a look in the package called "work"

Docs:
- Creating actorsJava|Scala
- Scheduling messagesJava|Scala

Exercises - Running tests in SBT

Running multiple test classes

$ ./sbt
> test-only workshop.part1.ComputeActorTest workshop.part2.ComputeSupervisorTest

Using wildcards and ~ (autorun)

$ ./sbt
> ~test-only workshop.part2*Test

Continuously run the part1 tests

$ ./sbt
> ~test-only workshop.part1.ComputeActorTest

Exercises - Running tests in Maven

Running multiple test classes

$ mvn test -Dtest=workshop.part1.ComputeActorTest,ComputeSupervisorTest

Using wildcards
```
$ mvn test -Dtest="workshop.part2.*"
```

Importing project to Eclipse

Generate Eclipse metadata
```
./sbt eclipse
```

Outline

Part 1 - Creating actors and sending messages
Part 2 - Actor supervision and death watch
Part 3 - Routers

Supervision through hierarchies

Actor supervision is recursive, enabling delegation of failure handling

Creating a supervisor

import akka.actor.OneForOneStrategy
import akka.actor.SupervisorStrategy._
import scala.concurrent.duration._

class Supervisor extends Actor {

    override val supervisorStrategy =
      OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1 minute, loggingEnabled = false) {
        case _: ArithmeticException      => Resume
        case _: NullPointerException     => Restart
        case _: IllegalArgumentException => Stop
        case _: Exception                => Escalate
      }

    def receive = {
      case p: Props => sender ! context.actorOf(p)
    }
}

SupervisorActor.java|scala

Using Death Watch

import akka.actor.{Props, Actor, Terminated, ActorRef, ActorSystem}

class DeathWatchActor extends Actor {

  override def preStart() {
    val greetingActor = context.actorOf(Props[VolatileGreetingActor])
    context.watch(greetingActor)
    greetingActor ! "print this message, please!"
  }

  def receive = {
    case Terminated(_) => println("looks like an actor has died :(")
  }
}

DeathWatchActor.java|scala

Start Hook
- Right after starting the actor, its preStart method is invoked.
- This method is called when the actor is first created.
- During restarts it is called by the default implementation of postRestart.
Restart Hooks
- The old actor is informed by calling preRestart with the exception which caused the restart and the message which triggered that exception.
- The initial factory from the actorOf call is used to produce the fresh instance.
- The new actor’s postRestart method is invoked with the exception which caused the restart.
- By default the preStart is called (by postRestart), just as in the normal start-up case.
- An actor restart replaces only the actual actor object; the contents of the mailbox is unaffected by the restart, so processing of messages will resume after the postRestart hook returns. The message that triggered the exception will not be received again. Any message sent to an actor while it is being restarted will be queued to its mailbox as usual.
Stop Hook
- After stopping an actor, its postStop hook is called, which may be used e.g. for deregistering this actor from other services. This hook is guaranteed to run after message queuing has been disabled for this actor, i.e. messages sent to a stopped actor will be redirected to the deadLetters of the ActorSystem.

Life-cycle of Actors

class LifeCycleActor extends Actor {
  def receive = {
    case e: Exception => throw e
  }
  override def preStart() {
    println("preStart() - called by FIRST actor-instance during startup")
  }
  override def postStop() {
    println("postStop() - called by ANY actor-instance during shutdown")
  }
  override def preRestart(reason: Throwable, message: Option[Any]) {
    println("preRestart() - called on ANY running actor about to be restarted")
  }
  override def postRestart(reason: Throwable) {
    println("postRestart() - called on a NEW INSTANCE of this actor after restart")
  }
}

LifeCycleActor.java|scala

What happens on an actor restart

What restarting means

Actor Lifecycle

Part 2 - Architecture

Part 2 - Exercises

Supervision
- Implement ComputeSupervisor
- Make tests in ComputeSupervisorTest green
Death Watch
- Implement ClientActor
- Make tests in ClientActorTest green

Docs:
- Creating a Supervisor StrategyJava|Scala
- Lifecycle Monitoring aka DeathWatchJava|Scala

Outline

Part 1 - Creating actors and sending messages
Part 2 - Actor supervision and death watch
Part 3 - Routers

Routers

Routers are not actors, they are specifically designed for concurrency
Akka comes with different routers

Router example

class ComputeRouter_1 extends Actor {
    val router = context.actorOf(RoundRobinPool(50).props(Props[Routee]), "router1")

    def receive = {
        case s: String => router.tell(s, sender())
    }
}

class Routee extends Actor {
    def receive = { case s: String => sender ! s.length() }
}

object ComputeRouterExample extends App {
    val router: ActorRef = ActorSystem("MySystem").actorOf(Props[ComputeRouter_1])
    router ! "how long is this string?"
}

ComputeRouter_1.java|scala

Part 3 - Exercises

Implement SuperComputeActor.java|scala
Make tests in SuperComputerActorTest.java|scala green

Play around with:
- Create multiple actors (one for each unit of work)
- Use a routerJava|Scala
- Use futuresJava|Scala

Datainn - Gathering traffic data with Akka

Vegvesenet skal høste 10.000 datameldinger om trafikken hvert sekund hele året

Datainn - Where does Akka fit in?

Datainn - Actor Design

Datainn - Lessons learned with Akka

Keep actors small and simple
Hard to understand actor hierarchy
High performance, but can be difficult to configure
Abstractions often low-level, despite being a large "toolkit"
Actor supervision create boiler plate code

Outline

What is Akka?

Motivation

Outline

The Actor Model

Hello Actor

Sending Messages

Scheduling Work

Part 1 - Exercises

Exercises - Running tests in SBT

Exercises - Running tests in Maven

Importing project to Eclipse

Outline

Supervision through hierarchies

Creating a supervisor

Using Death Watch

Life-cycle of Actors

What happens on an actor restart

Part 2 - Architecture

Part 2 - Exercises

Supervision

Death Watch

Outline

Routers

Router example

Part 3 - Exercises

Datainn - Gathering traffic data with Akka

Datainn - Where does Akka fit in?

Datainn - Actor Design

Datainn - Lessons learned with Akka

Datainn - Performance dashboard

Thanks!

Questions?