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. " 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.
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 <[email protected] <javascript:>>: > > 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 <[email protected]> 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 [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. >>> >> >> >> >> -- >> 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 [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. > > > > > *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 [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.
