Scala

Typed ask for Akka

Akka is a great tool for writing distributed applications. One thing that always surprised me though is that while being based on Scala, which is a very type-safe language, the elementary construct in Akka – an actor – is not really type safe. You can send any message to any actor, and get back any object in reply.

The upcoming 2.2 release of Akka will contain an experimental implementation of typed channels, which use macros to ensure type-safety in actor communication; but before that is final, here’s a simpler and less powerful approach, to add some typing to the ask pattern.

You can look at the ask pattern as a kind of asynchronous method invocation: you
 
send a message (its class corresponds to the method name) with some arguments, and expect a reply (method result). More specifically, we get back a Future, which will eventually hold the reply (if any). Note that the reply can also be of type Unit, corresponding to methods returning no result. Knowing when such “methods” complete may still be useful, though.

A very simple example of the basic ask pattern usage:

import akka.pattern.ask

case class LookupUser(id: Int)

// the actor impl should send back a message to the sender
val userFuture = actor ? LookupUser(10)

// userFuture: Future[Any]

userFuture onSuccess {
   case result => {
      // do something with the result
      // result has type Any 
   }
}

The not-so-nice thing here is that the return type of ? (see the AskSupport implementation) is Future[Any], as the actor may respond with any message. However ideally, when sending LookupUser we would want to get a Future[Option[User]], when sending UserCount a Future[Int] and so on.

This is in fact quite easy to implement. First of all, we must somehow embed the expected reply type in the message. For that we can use a trait, which takes the type of the expected response as a type parameter:

trait Replyable[T]

This can be used in the messages that we are sending to the actor:

case class LookupUser(id: Int) extends Replyable[Option[User]]
case class UserCount() extends Replyable[Int]

Now we need a variant of ? which returns a future with the right type parameter:

trait ReplySupport {
  implicit class ReplyActorRef(actorRef: ActorRef) {
    def ?[T](message: Replyable[T])
            (implicit timeout: Timeout, tag: ClassTag[T]): Future[T] = {
      akka.pattern.ask(actorRef, message).mapTo[T]
    }
  }
}

package object reply extends ReplySupport

You can see that we are simply re-using the existing ask implementation, and mapping the resulting future to the right type. The timeout is an implicit parameter of ask and ClassTag of mapTo, hence we must include them in the signature as well.

Usage is quite simple, in fact it’s almost the same as before, except for the import and that the future is of the right type:

import reply._

val userFuture = actor ? LookupUser(10)

// userFuture: Future[Option[User]]

userFuture onSuccess {
   case result => {
      // do something with the result
      // result has type Option[User] 
   }
}

That’s the actor-user side. What about the actor itself? How to ensure that if an actor receives a message of type Replyable[T], it will actually answer with T? As quite commonly in Scala, the answer again is a trait, which can be mixed into an actor:

trait ReplyingActor extends Actor {
  def receive = {
    case m: Replyable[_] if receiveReplyable.isDefinedAt(m) => {
      try {
        sender ! receiveReplyable(m)
      } catch {
        case e: Exception => sender ! Failure(e)
      }
    }
  }

  def receiveReplyable[T]: PartialFunction[Replyable[T], T]
}

And example usage:

class UserActor extends ReplyingActor {
   def receiveReplyable[T] = {
      case LookupUser(id) => Some(User(...))
      case UserCount() => 512
   }
}

Now this is all nicely type-checked. If we tried to return a String in the UserCount branch, we would get a compile-time error.
 

Reference: Typed ask for Akka from our JCG partner Adam Warski at the Blog of Adam Warski blog.

Adam Warski

Adam is one of the co-founders of SoftwareMill, a company specialising in delivering customised software solutions. He is also involved in open-source projects, as a founder, lead developer or contributor to: Hibernate Envers, a Hibernate core module, which provides entity versioning/auditing capabilities; ElasticMQ, an SQS-compatible messaging server written in Scala; Veripacks, a tool to specify and verify inter-package dependencies, and others.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Michel Daviot
Michel Daviot
11 years ago
Adam Warski
11 years ago
Reply to  Michel Daviot

See a similar discussion: http://www.warski.org/blog/2013/05/typed-ask-for-akka/#comment-903825795

In short, typed actors would do the job as well; however, when reading code which uses typed actors it isn’t that obvious that the invocations are async; also, typed actors are quite different than the “core” actor model (with message passing).

So I think both approaches have usages.

Back to top button