Hi Justin, First off, many thanks for taking a look and the feedback. Requester looks very promising, i'm looking over the sources now. In some respects i'm lucky my problem is quite straightforward . Its clear that in the general case addressed by Requester, this is a not a trivial problem - but i'm very impressed with it so far
Many Thanks Ian On Monday, 9 May 2016 19:09:56 UTC+1, Justin du coeur wrote: > > Frankly, your code looks about right -- if this is a one-off situation, > it's likely a good enough approach. You could also use pipeTo, but you'd > have to inject the originalSender into the communication, so I suspect it > would come out about equally complicated. > > I wouldn't normally talk up the Requester library > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjducoeur%2FRequester&sa=D&sntz=1&usg=AFQjCNENkT5TCnHjfQUcPZTLPcfiJyFSww> > > for a simple case like this, but since you asked, this code under Requester > would come out as roughly: > > case update: UpdateCommand => { > val targetActor = actors.getOrElse(update.id, throw new > RuntimeException("not available")) > for { > result <- targetActor.request(update) > } > { > sender ! result > ... do the caching locally... > } > } > > > Basically, Requester was written for complex multi-Actor interactions -- > instead of exposing Future via ask(), it exposes RequestM via request(). > RequestM intentionally looks a lot like Future but the completion handler > executes within the Actor's receive function, so you can safely work with > the Actor's state during the response. It also automatically preserves the > original sender, since this sort of pattern is so common. (Basically, it > is doing the ask and pipe under the hood, so your application-level code > doesn't have to worry about the dangerous Futures.) > > Mind, it's a third-party library, and still evolving, but I use it heavily > in production for Querki, and it's pretty stable by now. And in the grand > scheme of things, it's not *terribly* complex... > > On Mon, May 9, 2016 at 9:48 AM, Ian Clegg <[email protected] > <javascript:>> wrote: > >> Hi everyone, >> >> I'm looking for some advice. I have an actor whose state needs to be >> updated via a HTTP request. I'm using Akka HTTP with the Route DSL and an >> Ask pattern (this seems to be 'normal') >> >> onComplete(*broker ?* *UpdateCommand*(id, "something")) { >> case *Success*(u) => *complete*("updated") >> case _ => *complete*("An error has occured") >> } >> >> So an update message is sent to a broker as an 'Ask' so the result can be >> returned in the Http response. The broker locates the actor that needs to >> be updated based on the id passed in from the request and message. So the >> broker needs to forward the Ask on to the target, I know I can do this with >> a PipeTo - but I would also like the broker to receive the response so it >> can cache some data. So I guess i'm trying to Tee the response, sending it >> to myself and back to the original sender. >> >> This is what I have now and it feels nasty: >> >> def receive = { >> case update: UpdateCommand => >> val originalSender = sender # capture the original sender of >> the Ask, since we need to reply in a future continuation >> val targetActor = actors.getOrElse(update.id, throw new >> RuntimeException("not available")) >> targetActor.ask(update) onSuccess { >> case result => { >> originalSender ! result # respond to the original ask >> self.tell(result, targetActor) # tell it to ourself, but >> preseve the fact it came from endActor >> } >> } >> >> I'm pretty new to Akka and these patterns. Is there a nice way to do >> this? Maybe using a pipeTo somehow, or some other combination of functions? >> Do other people do this kind of thing >> >> Any tips appreciated >> Ian >> >> -- >> >>>>>>>>>> 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 https://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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
