Hi Roland "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."
I was a little surprised to read that. I thought there was some agreement that chained asks are tricky to manage. http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ I remember hearing Viktor say in Seattle a long time ago that ask was appropriate at the "edge" of the application, and that seems to be what I have arrived at, for each request: - 1 ask (currently necessitated by Akka HTTP) - per-request actor - tells with explicit replyTo from then on (ready for Akka Typed) I should have included the link to this thread in my reply to Robert https://groups.google.com/d/msg/akka-user/-VF0ZeIt054/TrXdX582AQAJ With Spray I could do 0 asks (a la net-a-porter), but only because the Route type was context => Unit, and I can see why you're changing that in Akka HTTP. Hence: https://github.com/akka/akka/issues/18431 In fairness, I suppose the two problems listed in the net-a-porter article also apply when making calls to external APIs (eg. Slick or Spray client) that also return futures, although the timeouts are configured once in that case. Seems to me this comment on the net-a-porter article has it about right. >>> natalinobusa on October 11, 2014 at 9:53 pm <http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/#comment-8399> said: An ask patter implements a lean actor. instantiating your own actor and setting the setReceiveTimeout as pretty much the same effect of defining a ask patter with a ask future timeout. Secondly, you are forced to pass the context to an akka actor with the risk of spreading response and request spary directive on both your spray actor as way as your perRequest Actor. Hence, it more a matter of taste then other. Once you are in the akka actor domain (the right part of your diagrams), I do agree with you that it makes much sense to tell messages back and forward rather then composing futures everywhere and defining timeouts all over the actor system. <<< This is such a perennial topic, it might warrant a section in the docs. On Sun, Sep 13, 2015 at 1:10 AM, Roland Kuhn <goo...@rkuhn.info> wrote: > Sorry, that should have read “Hi Robert” (don’t know where “Richard” came > from). > > 13 sep 2015 kl. 09:59 skrev Roland Kuhn <goo...@rkuhn.info>: > > 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 <kray...@gmail.com>: > > 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 <kra...@gmail.com> 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 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. >>> >> >> > -- > >>>>>>>>>> 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. > > > > > *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. > > > > > *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.
