See the thread(s) and Activator templates on per-request actors. With Spray I avoided ask completely by using per-request actors and messages with a replyTo property. Others use much more Future-centric approaches.
Sent from my phone - will be brief > On Sep 12, 2015, at 5:15 PM, kraythe <[email protected]> wrote: > > 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, >> 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]> 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: >>> 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. >>> It has to be done in one call (rebuilding front end puts the task out of >>> fiscal reach) >>> 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]. >>> 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. > > -- > >>>>>>>>>> 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. -- >>>>>>>>>> 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.
