Great explanation Arne - thank you!
I think I have all pieces except one:
I call web services in parallel, creating Futures. Futures are then
converted to one Future (like Future.sequence).
Do I reach backpressure in case of "too many requests" when router respond
with Source
Great explanation Arne - thank you!
I think I have all pieces except one:
I call web services in parallel, creating Futures. Futures are then
converted to one Future (like *Future.sequence*).
When, in router, I create response with Source and
set OverflowStrategy.backpressure
2017-04-26 10:15
> /_Question_:/
> - does it make really sense to create dispatcher pro web service client
> or one for all? Do you've any experience with it?
> - is it better to use Dispatcher with fork-join or fixed-size one?
Using the default pool fully utilizes the CPU, and using a separate
dispatcher will
Thank you Konrad for really fast response!
I read the docs again and if I correct understood my configuration
can/should be like this one:
*1. Dispatcher(s)*
One dispatcher for all web service clients with fixed size. Size of the
pool correspond to CPU amount (16 for 16 cores)
*or*
dispatcher
Dispatcher (executor) is mostly important if you're doing bad things on it
- like blocking on responses for example.
If you're handling things in async / reactive ways the default akka
dispatcher is fine most of the time, just don't block on it (read this:
Hi,
I've Akka HTTP service which calls 5 other services using Akka HTTP client
(Host-Level Client-Side API). Currently I have executor context per service
(host/port).
What is the best practice for setting executor context? I mean, should I use
fork-join or cached or fixed thread pool or maybe
