Thanks again for your interesting points, jim I already have a separate dispatcher for the actors and one for the system.
Am Mittwoch, 18. November 2015 18:30:13 UTC+1 schrieb Jim Hazen: > > That's possible. Your actor won't be able to get more work until it > completes its receive. You could: > > A: look into actor pool/routers. This will give you more receive blocks > to work with, increasing concurrency. > B: look into spending less time within your receive block, maybe by > delegating the real work to a dispatched Future. If you go this route > you'll have the ability to use a thread-pool-dispatcher for the > longer/blocking work and your fork-join-dispatcher for your very fast > receive executions. > > I tend to end up with option B. With my Spray services, using the dispatch > directive takes the real work out of http dispatching thread. With actors > that are mostly IO, since Spray IO is async, you get essentially the same > thing. So when I find I have dense cpu intensive code, I offload that work > into another dispatcher and let the actor drive work into this ecexutor as > quickly as it can. > > At the very least, option B should help you drive up cpu utilization. > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
