Good point. I think you are spot on here -- this would be a minefield in practice, even more so than occasionally forgetting not to use Futures inside Actors. I hadn't thought about switchable Actor behaviors.
(I tend to agree with this blog post and we use a lot more Futures than Actors in our Akka HTTP (and Spray) apps: http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/ . Perhaps the upcoming typed Actors will make things better in that regard.) (I'll post your comment as an answer to my SO question.) Thanks, Rich On Monday, September 28, 2015 at 3:18:20 PM UTC+1, rkuhn wrote: > > My main consideration here is that such a dispatcher would make it very > convenient to have multiple concurrent entry points into the Actor’s > behavior, where with the current recommendation there is only one—the > active behavior. While classical data races are excluded by the > synchronization afforded by the proposed ExecutionContext, it would still > allow higher-level races by suspending a logical thread and not controlling > the intermediate execution of other messages. In a nutshell, I don’t think > this would make the Actor easier to reason about, quite the opposite. > > Regards, > > Roland > > 28 sep 2015 kl. 15:47 skrev Richard Bradley <richard.brad...@gmail.com > <javascript:>>: > > 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 > > <http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F26912919%2Fhow-to-run-futures-on-the-current-actors-dispatcher-in-akka&sa=D&sntz=1&usg=AFQjCNFrw_efPkRYDImfEdPPSNGlFw0Juw> > > 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 <uja...@gmail.com> 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 akka-user+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com > <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 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.
