Akka dispatcher and router

Question

After reading the Akka documentation and also some posts online, I still don't have a clear understanding of the relationship between a router and a dispatcher.

1) Does a router always use a dispatcher for dispatching to the routees? Can a router do its job without using a dispatcher?

2) If there are no additional dispatchers defined in the configuration, my understanding is that the default dispatcher will be used. In my actor system, I have a cluster with two producer actors that use the router actor and three consumer actors. The producers and consumers are all running in different JVMs--what does it mean for an actor system to have one default dispatcher?

My understanding is that a dispatcher is like a thread pool executor. In this case, in different JVMs, wouldn't each JVM have its own instance of a dispatcher and its own thread pool executor?

3) Related to the above question (https://doc.akka.io/docs/akka/current/dispatchers.html#problem-blocking-on-default-dispatcher):

Using context.dispatcher as the dispatcher on which the blocking Future executes can be a problem, since this dispatcher is by default used for all other actor processing unless you set up a separate dispatcher for the actor.

If the actors are running in different JVMs, is the above still applicable? If so, what does it mean?

Answer 1

(1a) Does a router always use a dispatcher for dispatching to a routee?

Yes.

(1b) Can a router do its job without using a dispatcher?

No. All actors, regardless of whether or not they are routers, run on a dispatcher.

(2) ...in different JVMs, wouldn't each JVM have its own instance of a dispatcher and its own thread pool executor?

Yes, essentially. If your system consists of multiple JVMs, then each JVM will have its own ActorSystem (for example, using Akka Cluster). Each ActorSystem configures its own dispatcher(s) independently of any other ActorSystem.¹ If you don't add a dispatcher, the default dispatcher will be used.

(3) "Using context.dispatcher as the dispatcher on which the blocking Future executes can be a problem, since this dispatcher is by default used for all other actor processing unless you set up a separate dispatcher for the actor."

If the actors are running in different JVMs, is the above still applicable? If so, what does it mean?

Yes, the guidelines about dealing with blocking operations would apply if you have actors running on multiple JVMs. Each JVM would have its own ActorSystem, and each ActorSystem would need to set up a dedicated dispatcher to deal with blocking operations, as the documentation you quoted recommends.

---

¹In fact, you can have more than one ActorSystem on a JVM. From the documentation:

Several actor systems with different configurations may co-exist within the same JVM without problems, there is no global shared state within Akka itself.

Answer 2

Some small corrections to Jeffreys otherwise great answer: it is possible to run a router which routes messages on the calling thread (see the first example in the docs), and that thread could potentially be an arbitrary non-actor thread, so that would not in itself require a dispatcher.

The actor the router routes to, however, like any other actor will always be running on a dispatcher.

It is also quite common to run a router as a separate actor, and in that case it will run on a dispatcher (described in the second section of the router docs).

The mailbox is the queue of messages for an actor and putting a message in it will lead to the actor processing that message (or a few in one batch) being scheduled on the dispatcher. When a mailbox is empty the actor is not scheduled to execute which means that a large amount of actors can share a dispatcher with a small number of threads.

If one of those actors take "a few minutes" to execute, that can lead to starvation - that no other actor gets to execute, including actors that deal with cluster state and internals of Akka, therefore it is important to isolate them onto their own dispatcher. See the blocking needs careful consideration section of the docs.