Be sure you aren't just separating your actors onto their own collective
executor, but put the work each actor is doing onto an executor. The goal is to
drive as much work as possible into these executors, and free up akka's
executors to simply drive this work into to those other executors as
They're going to have to figure a way around that. Maybe with better
protocoling around demand signals. The gem of Akka is its location
transparency. I find it hard to believe they'd leave this functionality out of
Streams forever. Sure, it'll be work to develop good signaling protocols for
You could use ActorSubscribers and Publishers here. Or depending on what your
response handling logic is, use a simple forEach sink to process the results.
I'm guessing you'd model your indexer as a flow component and then put a
broadcast on the output channel. So a flow graph that looks
You're right. In this case we don't need the bcast at all. Dunno what I was
thinking, but it made sense at the time. :)
-Jim
-- Sent from my mobile device
On Feb 22, 2015, at 10:08 AM, Jakub Liska liska.ja...@gmail.com wrote:
Yeah, but as I said those are remote actors So this is not
Hmm. Then I must have been playing with the setting around the same time. It's
definitely related to overall thread scheduling. Poke around the reference.conf
files in the core akka jars. There should be a description of the overall
methodology in there as well. Timer granularity and number of
