On Tue, Apr 25, 2017 at 6:21 AM, Vishwa Bhat <[email protected]> wrote:
> Suppose there is a sequence of dependant operations say: > > a. Build X > > b. Insert X into Database > > c. Find Y in the Database > > d. Get Z from some Computation and return it > > Assuming all the above operations are blocking. > > [...] > 3. One final question is, even if followed various approaches of actors I could not hit concurrency level beyond 1000. What is the optimal value for real world scenarios, not hello world ones. You've probably got your own answer here. The thing is, Actors aren't magic. They allow you to tame concurrency to some degree, but blocking is blocking, and blocking is *always* evil. If your lower-level operations are all blocking, that's going to impose hard limits on how much practical concurrency you can get in the system. If you have some blocking operations and some non-blocking ones, in different Actors, then you should look into Dispatchers -- the standard approach is to assign the blocking operations to their own Dispatcher, so that the non-blocking Actors can progress at their own speed without having to share the blocked threads. But if you are doing a lot of blocking database I/O, odds are that Akka can't help. (This is why Akka systems use non-blocking database APIs whenever possible.) Now my first question is, > > 1. How do I approach in building Actor model for the above scenario? > I recommend stepping back and rethinking the question in terms of "what is this Actor *responsible* for?". An Actor isn't a collection of random operations -- it is typically managing a high-level business object, or a workflow, or something like that. You haven't given us enough information here to be able to really answer the question, but the general principle is that you should be building an Actor that manages a reasonably isolated concept. > #Another way is to *wrap all the operations inside one actor*. The better > part with this approach is it does not create that many actors as approach > one but it certainly ruins the purpose of actors because AFAIK if an actor > has severe blocking code, it almost mimics a Java thread itself. > > Yep -- blocking is evil. Indeed, blocking inside of an Actor is always a bit problematic, and if *all* of your Actors are blocking, then odds are pretty good that the system is going to have problems. Mind, from your description I'm not at all sure whether Akka is an appropriate solution in the first place. Here's a question: are you managing any in-memory state? If not -- if this application is nothing more than doing series of database operations -- then I almost certainly wouldn't use plain Akka for it. (I might use Akka Streams, but that's for very different use cases.) 2. I use Play framework with Java, Is there any way to use only actors > until controller level (after which I am forced to send* > CompletionStage<Result>* to avoid blocking API call anyway)? For now I'm > using *Patterns.ask(..) *to wait for the data. > > Hmm -- what do you mean by "wait"? Having a Play Action call ask() is absolutely standard, and often the correct solution, but that's precisely because it *doesn't* wait -- ask() returns a Future, which you pass to Play, and Play knows how to resolve that in a non-blocking way. There's normally no waiting involved... -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
