Menu
Couldn't find any info on this. I have a Akka/Spray based service and was always using ExecutionContext.global if i wanted to write some async code with std scala Future. Are there any benefits from using a dispatcher in akka based app rather than importing a global one? And also are there are any disadvantages from mixing (some parts are using akka's dispatcher and other parts scale's global)?
742
This is an event-based dispatcher that binds a set of Actors to a thread pool. Characteristics of default dispatcher are: Every actor has its own mailbox. The dispatcher can be shared among any number of actors. It is designed to be used when you have a non-blocking (async) code in your actor.
The thread pool executor dispatcher is implemented using by a java. util.
Futures are the standard mechanism for writing multithreaded code in Scala. Whenever we create a new Future operation, Scala spawns a new thread to run that Future's code, and after completion it executes any provided callbacks.
Don't use Akka default Dispatcher for execution of blocking calls in Future-s - in this case you can get all your Actors sitting on the default Dispatcher fully hanged in case of all threads of the default Dispatcher are blocked by blocking calls in such Future-s.
Usage of different Dispatcher-s for different Actor types (and especially for Future-s that do blocking calls) is known as Bulkhead Pattern.
ExecutionContext.global is a ForkJoinPool (by default) that use scala.concurrent.context.minThreads/maxThreads/numThreads settings for configure number of threads. So, IMHO, you can use it for Future-s execution instead of any other Akka Dispatcher with fork-join-executor.
But I would suggest to use a separate Akka Dispatcher for bulkheading just to have all Dispatchers configured in a single place (in Akka config).
111
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
