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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
