Creating Typed Actors¶

IMPORTANT: The Typed Actors class must have access modifier ‘public’ (which is default) and can’t be an inner class (unless it is an inner class in an ‘object’).

Akka turns POJOs with interface and implementation into asynchronous (Typed) Actors. Akka is using AspectWerkz’s Proxy implementation, which is the most performant proxy implementation there exists.

In order to create a Typed Actor you have to subclass the TypedActor base class.

Here is an example.

If you have a POJO with an interface implementation separation like this:

import akka.actor.TypedActor

trait RegistrationService {
  def register(user: User, cred: Credentials): Unit
  def getUserFor(username: String): User
}

public class RegistrationServiceImpl extends TypedActor with RegistrationService {
  def register(user: User, cred: Credentials): Unit = {
    ... // register user
  }

  def getUserFor(username: String): User = {
    ... // fetch user by username
   user
  }
}

Then you can create an Typed Actor out of it by creating it through the ‘TypedActor’ factory like this:

val service = TypedActor.newInstance(classOf[RegistrationService], classOf[RegistrationServiceImpl], 1000)
// The last parameter defines the timeout for Future calls

val service = TypedActor.newInstance(classOf[Service], new ServiceWithConstructorArgs("someString", 500L))

import akka.actor.TypedActorConfiguration
import akka.util.Duration
import akka.util.duration._

    val config = TypedActorConfiguration()
      .timeout(3000 millis)

val service = TypedActor.newInstance(classOf[RegistrationService], classOf[RegistrationServiceImpl], config)

Sending messages¶

Messages are sent simply by invoking methods on the POJO, which is proxy to the “real” POJO now. The arguments to the method are bundled up atomically into an message and sent to the receiver (the actual POJO instance).

// method invocation returns immediately and method is invoke asynchronously using the Actor Model semantics
service.register(user, creds)

// method invocation is asynchronously dispatched using the Actor Model semantics,
// but it blocks waiting on a Future to be resolved in the background
val user = service.getUser(username)

class MathTypedActorImpl extends TypedActor with MathTypedActor {
  def square(x: Int): Future[Integer] = future(x * x)
}

// create the ping actor
val math = TypedActor.newInstance(classOf[MathTyped], classOf[MathTypedImpl])

// This method will return immediately when called, caller should wait on the Future for the result
val future = math.square(10)
future.await
val result: Int = future.get

Stopping Typed Actors¶

Once Typed Actors have been created with one of the TypedActor.newInstance methods they need to be stopped with TypedActor.stop to free resources allocated by the created Typed Actor (this is not needed when the Typed Actor is supervised).

// Create Typed Actor
val service = TypedActor.newInstance(classOf[RegistrationService], classOf[RegistrationServiceImpl], 1000)

// ...

// Free Typed Actor resources
TypedActor.stop(service)

When the Typed Actor defines a shutdown callback method (Fault Tolerance Through Supervisor Hierarchies (Scala)) it will be invoked on TypedActor.stop.

How to use the TypedActorContext for runtime information access¶

The ‘akka.actor.TypedActorContext’ class Holds ‘runtime type information’ (RTTI) for the Typed Actor. This context is a member field in the TypedActor base class and holds for example the current sender reference, the current sender future etc.

Here is an example how you can use it to in a ‘void’ (e.g. fire-forget) method to implement request-reply by using the sender reference:

class PingImpl extends TypedActor with Ping {

  def hit(count: Int) {
    val pong = context.getSender.asInstanceOf[Pong]
    pong.hit(count++)
  }
}

If the sender, sender future etc. is not available, then these methods will return ‘null’ so you should have a way of dealing with that scenario.

Messages and immutability¶

IMPORTANT: Messages can be any kind of object but have to be immutable (there is a workaround, see next section). Java or Scala can’t enforce immutability (yet) so this has to be by convention. Primitives like String, int, Long are always immutable. Apart from these you have to create your own immutable objects to send as messages. If you pass on a reference to an instance that is mutable then this instance can be modified concurrently by two different Typed Actors and the Actor model is broken leaving you with NO guarantees and most likely corrupt data.

Akka can help you in this regard. It allows you to turn on an option for serializing all messages, e.g. all parameters to the Typed Actor effectively making a deep clone/copy of the parameters. This will make sending mutable messages completely safe. This option is turned on in the ‘$AKKA_HOME/config/akka.conf’ config file like this:

akka {
  actor {
    serialize-messages = on  # does a deep clone of messages to ensure immutability
  }
}

This will make a deep clone (using Java serialization) of all parameters.