Richard, what would happen if the actor is dead when the Future is to be executed?
On Mon, Sep 28, 2015 at 3:47 PM, Richard Bradley < [email protected]> wrote: > On this subject, I've wondered for a while why Actors don't expose an > ExecutionContext which executes all Future callbacks on their event loop, > thus eliminating this problematic restriction on Future callbacks entirely? > > http://stackoverflow.com/questions/26912919/how-to-run-futures-on-the-current-actors-dispatcher-in-akka > > I suppose it would be a backwards compatibility break and might possibly > introduce some unexpected bottlenecks, but it seems to me like it would be > a better tradeoff than trying to outlaw Future operations in an Actor > context, which is a common pitfall for Akka users. > > Your Requester library, Justin, looks to do just that for the specific > case of Asks. It looks pretty useful; I might start using it. > > > On Tuesday, September 22, 2015 at 8:05:32 PM UTC+1, Justin du coeur wrote: >> >> On Tue, Sep 22, 2015 at 9:20 AM, John Ulric <[email protected]> wrote: >> >>> @Heiko, @Roland, thanks. The callback in my case essentially makes a >>> decision where to send the future result (to self, to a delegee actor, to >>> the calling actor) plus some error handling, logging and monitoring, so it >>> is a pipe, essentially. I found the code more readable when I make these >>> decisions here in the callback, instead of piping the result to self, >>> making the decisions, and forwarding the message again. Do you think this >>> is an acceptable pattern or would you absolutely discourage to the use of a >>> callback here? >>> >> >> If you want to use this pattern, I recommend you look into the Requester >> <https://github.com/jducoeur/Requester>library, which is designed to >> provide ask-like callbacks while actually *operating* like pipeTo. This >> sort of thing is why I wrote Requester. >> >> Suffice it to say, Requester adds the request() function, which is >> similar to ask() but returns a RequestM instead of a Future. It has many >> of the same functions as Future -- onComplete, map, flatMap, etc -- but >> they actually run in the Actor's main receive loop instead of in some >> arbitrary thread. >> >> However, I will caveat that it's never been sanity-checked with Java -- I >> only use Scala, and haven't really given much thought to the API from a >> Java perspective. If you find problems using it from there, please bring >> them to my attention. >> > -- > >>>>>>>>>> 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]. 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.
