akka patterns.ask implementation details

Question

We have a use case where we have a set up like following: Master type of Actor and Worker type of Actor.

The master receives work request for an input and uses workers to orchestrate and generate result.

There is a plan to create a Java class named client.java. This creates a new instance of master and sends work to it. This client uses - Patterns.ask to get future pointers and later blocks on it until results are arrived.

Patterns.ask(master, initialMessage, t);      
Await.result to get the message

The internal documentation of Patterns.ask says a temporary actor will get created. But, when I invoke and try to print the hashCode of the sender inside master, it seemed same actor every time.

I have following concerns:

1. How is concurrent invocations of Patterns.ask managed? Can it happen like a thread after calling, ask gets a future pointer but wrong data is put in it?
2. How does it guarantee that Future pointers are filled with relevant responses only and not mixed up with responses from others?
   For ex: FutureX = future Expecting X message
   FutureY = future Expecting Y message
   Can it ever happen that FutureX get Y and FutureY gets X?

Answer 1

I haven't read Patterns.ask internal documentation but I assume it utilizes ActorRef.forward(message, context) in order to stick to the message sender.

Also, you shouldn't block (Await.result()) and should apply callbacks instead by using the factory method provided by akka.dispatch.Futures. You'll be able to chain and recover Future tasks (and more) and get a way better application performance as described here:

http://doc.akka.io/docs/akka/2.3.12/java/futures.html#Functional_Futures

Answer 2

All actors run on atleast one or multiple thread pools (which you can configure in Akka's default application.conf file. These are regular Java ExecutorService's so if you want to know more, look at the ExecutorService source code). The beauty of Akka (actually, the actor model) is that every regular Actor is isolated and untyped, forcing you to "ask" an Actor to mutate a state or reply with a state, opposed to how you would do it using normal threads.

I assume Akka does all the expensive locking and low-level concurrency issue solving internally when two actors both run on different threads so you, as the developer don't have to. Every actor has its own mailbox (which is backed by a ConcurrentLinkedQueue, it is NOT blocking). This means that whatever message you send to an actor, whether it's a fire-and-forget type or a request for state (ask), it is enqueued to the mailbox and sequentially handled in FIFO order.