Sorry, that should have read “Hi Robert” (don’t know where “Richard” came from).
> 13 sep 2015 kl. 09:59 skrev Roland Kuhn <[email protected]>: > > Hi Richard, > > we may have touched on that earlier (or I am just having a déja-vu): when > sending a message using ask() no thread and no actor is “tied up”, nothing is > blocked, hence there cannot be the executor-hell kind of deadlock, it is > impossible. For a rough sketch consider this (only one level deep, but should > give you the general idea): > > import akka.actor._ > import akka.pattern.{ ask, pipe } > import akka.util.Timeout > > import scala.concurrent.duration._ > import scala.concurrent.Future > > object Scratch { > case class Get(name: String) > case class Customer(id: Long) > case class Result(name: String, orders: Seq[Order]) > case class Failure(name: String) > > case class GetOrders(customerId: Long) > case class OrderList(orderIds: Seq[Long]) > > case class GetOrder(id: Long) > case class Order(id: Long, stuff: String) > } > > class Scratch(customerInfo: ActorRef, orderInfo: ActorRef) extends Actor { > import Scratch._ > import context.dispatcher > > implicit val t = Timeout(100.millis) > > def receive = { > case Get(name) => > val orders = for { > customer <- getCustomer(name) > OrderList(ids) <- getOrders(customer.id) > orders <- Future.sequence(ids.map(id => getOrder(id))) > } yield Result(name, orders) > > orders.recover { > case ex => Failure(name) > }.pipeTo(sender()) > } > > private def getCustomer(name: String) = (customerInfo ? > Get(name)).mapTo[Customer] > private def getOrders(id: Long) = (orderInfo ? > GetOrders(id)).mapTo[OrderList] > private def getOrder(id: Long) = (orderInfo ? GetOrder(id)).mapTo[Order] > } > > The Actor only starts the process and then is free to serve the next > request—which obviously is not a good idea without some tracking of how many > requests were started but not yet finished, but that is easy to add. > > BTW: it might not be a good idea to allow cycles like the orderInfo service > asking the front-end for more customer info, independent of your (unfounded) > worry about deadlocking, because this can easily devolve into an infinite > loop—and that has nothing to do with Actors. > > If you still want to do things without using ask() then you can simply create > a per-request Actor that performs the above process, receiving reply messages > normally in its behavior, no futures involved. But as long as the logic is as > simple as shown above (in particular the error/failure handling) then ask() > will be superior in every respect. > > Regards, > > Roland > >> 13 sep 2015 kl. 02:15 skrev kraythe <[email protected] >> <mailto:[email protected]>>: >> >> 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: >> 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/ <http://akka.io/docs/> >> >>>>>>>>>> Check the FAQ: >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> >>>>>>>>>> <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 >> <http://groups.google.com/group/akka-user>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> >> >>>>>>>>>> Check the FAQ: >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> >>>>>>>>>> <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] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> Visit this group at http://groups.google.com/group/akka-user >> <http://groups.google.com/group/akka-user>. >> For more options, visit https://groups.google.com/d/optout >> <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/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <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.
