Because they rely on waiting some amount of time for something to come back from elsewhere and that means that you tie up the actor while you are waiting. So our customer actor fires off futures for all his orders, then they fire off futures for all of the items. It is a truism that eventually someone will put in a cycle that goes back to the customer to get some item (an account number for tracking? something) that then results in a deadlock. All the customer actors are busy, the pool is exhausted and those "get tracking number account") calls cannot complete because they are in line behind things in the actors blocking more messages from being processed. Such is the nightmare of executors, constant combat with deadlocks. If I could design a system that works in one direction, not tieing up resources waiting for things to come back then deadlock worries are behind me.
-- Robert On Saturday, September 12, 2015 at 6:26:14 PM UTC-5, Justin du coeur wrote: > > Hmm. Which problem are you concerned about with ask()? > *Architecturally*, the ask pattern seems decently well-suited to the > problem -- fire off a bunch of asks, maybe using Future.sequence() to > collect the results together. Ask has some real issues when used *inside* > of an Actor, but those can be worked around with some discipline, or you > can use Requester <https://github.com/jducoeur/Requester>, which is a > more Actor-friendly version of the same general pattern. > > But I'm not entirely clear on what you're trying to avoid here. I mean, > if you're trying to build a really scalable system, Future and ask() are > often crucial elements, so it would be helpful to get a sense of why you > *don't* want to use them. (Indeed, it's a bit hard to see how to do this > completely without Future -- I can't think of how offhand, since the > initial call *has* to send out a bunch of distributed work, so it's almost > certainly going to wind up with a Future handle for that...) > > On Sat, Sep 12, 2015 at 6:37 PM, kraythe <[email protected] <javascript:>> > wrote: > >> Greetings, >> >> I am completely sold on Akka and its abilities. I am even considering it >> for a game server (though Id have no idea how to get physics in there >> without reinventing the wheel, JNI maybe). What I am wondering about is a >> common paradigm in my applications. Basically it goes like this: >> >> Customer calls load balancer and gets routed to a server and is >> requesting a set of JSON that contains their customer information , a sub >> element with the JSON for each order and then a sub element in each order >> for the items in the order. Now If I were to do this traditionally I would >> have a method that calls another which calls another to get the successive >> level of detail. That isn't scalable so I change it to use completable >> futures. Now when the customer makes their request, the server fires off a >> set of completable futures, one for each order which in turn fires off >> futures to get the order item details. Problem is now I am in basically >> executor hell. >> >> Now if I decide to do this with actors, one method is to use the ask >> pattern but I have seen enough articles to convince me that the ASK pattern >> doesn't leave me much better off than my completable futures. So can it be >> done only with tell? How indeed? That is the purpose of this post. >> >> For the sake of the answer here are the requirements: >> >> 1. The system must return a json of the customer object with some >> details about the customer, a list of their orders and for each order ad >> sub list of items. >> 2. It has to be done in one call (rebuilding front end puts the task >> out of fiscal reach) >> 3. You cant use Ask or any variant of a future. >> >> Any suggestions? :) >> >> Thanks >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- >>>>>>>>>> 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.
