ask() returns a future. You can do things like use Future.sequence, or for-comprehensions.
That said, in my project we worked pretty hard to avoid using the ask() pattern. http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ On Wed, Aug 26, 2015 at 9:11 AM, kraythe <kray...@gmail.com> wrote: > Im not attempting to rant, sorry. Im just frustrated at being told what I > percieve is, "hey your entire software structure is wrong, rewrite it all." > But lets leave that as it is. > > So you are saying if I invoke an ask() inside an actor which invokes an > ask() inside another actor that there is no blocking? What if I need ALL of > the results of process be for a collection of data to finish A? I.e. A has > a collection of IDs and to finish process A, he has to invoke process B on > every one of those ids and get the data back. Now I can have process b send > it back to A but then they would all arrive as separate distinct messages, > not the collection we need to complete process A. This is where the > confusion sets in. I CANT finish A without all of the Bs comming back and > at some point if a B calls an A actor and the pool of A actors are all busy > it would seem to be a problem. You are saying this is not the case? > > class A { > override def receive : Receive = { > case msg: Msg1 => > // get domain object. > // For each id in a collection invoke ask() on actor B > // when all ask futures complete ... collect results and add to info > sender ! info > } > } > class B { > override def receive : Receive = { > case msg: Msg1 => > // get domain object. > // Add some information to result. > // send ask() to actor A to get some piece of info. > sender ! info > } > } > > So what am I missing here ? > > > On Wednesday, August 26, 2015 at 11:01:16 AM UTC-5, rkuhn wrote: >> >> Hi Robert! >> >> 26 aug 2015 kl. 17:40 skrev kraythe <kra...@gmail.com>: >> >> However, this has to be combined with some synchronous calls. Many parts >> of the system are Asynch but not all. We have users hitting web pages >> expecting to get certain data. We cant say "thanks for your submission and >> we will mail you your account information. " >> >> >> From this I assume that you assume (yes, I know, double-bad, please >> correct if wrong!) that the web server is implemented as some sort of >> synchronous routine that needs to present the client response as its return >> value—but this is not at all the case. If you look at Play (which has been >> around for quite a while) and the upcoming Akka HTTP then you’ll notice >> that responses can well be presented in an asynchronous fashion, and that >> is even the most common mode of operation. >> >> We need to go fetch that information which might involve nested calls to >> several actors and that might recurse to some of the same actors. So we >> have a situation where user hits a web page and it invokes ask() on Actor A >> which has a collection of Data to be gotten from Actor B which in turn >> needs some info from Actor C. Finally Actor C requires a peice of >> information from actor A (a different piece of information) and then it is >> all returned. Now I cant complete process A until all of this is done and >> in an executor concurrent world that means DEADLOCK if each invocation >> doesn't have its own executor. >> >> >> Again, I must infer from your wording that you assume that using the ask >> pattern somehow blocks actor A—but that is not at all the case. The ask >> pattern is a slightly more efficient short-hand for creating a new >> single-use actor that is used as the sender for the message that is sent to >> the target ActorRef, so that the eventual reply will be received by that >> mini-actor which only completes the associated ask-Future and then shuts >> itself down. There is no blocking in any of this. If you need to transform >> the results (e.g. by aggregating replies from multiple back-end services) >> then you do that by using the non-blocking compositional features of >> Scala’s Futures; non-blocking composition is also used to complete the >> Future that finally transmits the HTTP response back to the client. Because >> all of this is non-blocking the class of thread-and-lock deadlock that you >> are referring to is simply impossible—of course you can still implement >> logical deadlocks where two actors A and B each wait for the other to make >> the first step, but that is not a problem in the case we are discussing. >> >> To your rant below I can only say that thousands of production users >> prove the opposite—and integrating “legacy” components definitely is the >> norm and not exceptional. I’m currently writing the chapter of Reactive >> Design Patterns that describes how this is done, so here the hint must >> suffice that whatever you want to bring in you just wrap inside an Actor >> and expose a message-driven interface to the Akka-based part of your system. >> >> Regards, >> >> Roland >> >> >> Now one can say, "Don't design a system like this" and I can reply "ok, >> Ill just go to my boss and say we have to throw away 20 million in capital >> investment and redesign it with another 20 million to get the right system >> that looks good to the development world." Im afraid that would not end >> well. Furthermore, I don't know I could ever get around the problem of >> needing synchronous calls at times. Users interacting on a web page need >> things synchronously. Of course we could just get rid of the pesky users >> and the system would look great. Of course we wouldn't have a business. >> >> I am sorry but I am more than a bit frustrated hearing stuff like that >> from the Akka community. Im not talking about use cases that are way out of >> the norm. This is the type of thing that powers millions of web sites. Now >> I guess it could be you come back and say "Well, Akka is not the system to >> handle this." In which case I wonder what it is for at all. But if I cant >> handle this simple use case in Akka then it is of no use to me and I might >> as well leave the system using completable futures and Executors and strip >> out all Akka references. Thats not that hard since I haven't wormed it that >> far into the system yet. The documentation and promotional materials >> advertise Akka as solving the problems of concurrent, highly scalable >> systems. However, if this simple easy use case is not answerable then I >> question the literature. >> >> -- Robert >> >> On Wednesday, August 26, 2015 at 2:27:26 AM UTC-5, rkuhn wrote: >>> >>> The normal way to implement this would not use the ask pattern: if A >>> wants to know something and sends GetSomething to B, but B does not have it >>> and needs to defer to C, then in the Actor world it is possible and >>> completely idiomatic to have C send the result back to A directly. This is >>> the big difference between ActorRefs (which can be passed around for >>> arbitrary messaging patterns) and RPC (which is strictly request–response). >>> >>> Regards, >>> >>> Roland >>> >>> 26 aug 2015 kl. 03:17 skrev kraythe <kra...@gmail.com>: >>> >>> Call another actor using an ask pattern. >>> >>> On Tuesday, August 25, 2015 at 7:22:00 PM UTC-5, √ wrote: >>>> >>>> define "wait for the responses to send back to the caller" >>>> >>>> On Tue, Aug 25, 2015 at 12:04 PM, kraythe <kra...@gmail.com> wrote: >>>> >>>>> Lets say that we create a pool of 5 actors using round robin logic and >>>>> then we send 5 messages at the same time and those messages in the course >>>>> of being processed send another 5 messages each to the actor and wait for >>>>> the responses to send back to the caller. If this was a java executor it >>>>> would eventually deadlock waiting for the second set of calls to complete. >>>>> Is the same deadlock possible with Akka? If not then what would prevent >>>>> it? >>>>> >>>>> Thanks in advance. >>>>> >>>>> -- >>>>> >>>>>>>>>> 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+...@googlegroups.com. >>>>> To post to this group, send email to akka...@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> √ >>>> >>> >>> -- >>> >>>>>>>>>> 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+...@googlegroups.com. >>> To post to this group, send email to akka...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> >>> *Dr. Roland Kuhn* >>> *Akka Tech Lead* >>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM. >>> twitter: @rolandkuhn >>> <http://twitter.com/#!/rolandkuhn> >>> >>> >> -- >> >>>>>>>>>> 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+...@googlegroups.com. >> To post to this group, send email to akka...@googlegroups.com. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> *Dr. Roland Kuhn* >> *Akka Tech Lead* >> Typesafe <http://typesafe.com/> – Reactive apps on the JVM. >> twitter: @rolandkuhn >> <http://twitter.com/#!/rolandkuhn> >> >> -- > >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
