Hi Daniel, 13 mar 2014 kl. 23:06 skrev Daniel Armak <[email protected]>:
> On Thu, Mar 13, 2014 at 11:27 PM, Roland Kuhn <[email protected]> wrote: > Futures very cleanly model local dataflow. Actors very cleanly model > distribution and concurrency. My guess is that if you try to create an > abstraction in-between then it will have the disadvantages of both and the > advantages of neither. > > I think that's right, and I'm starting to think it might help to have a > cleaner way of combining futures with actors. (At least it would help me, if > not others.) There is the Aggregator pattern which helps in certain typical situations. > > In one direction, I sometimes want an actor not to process any further > messages until a Future completes. This is because a message caused the actor > to do something implemented in a Future-based library and I want to serialize > operations against that library, as if it were an internal implementation > detail of the actor. > > I could become an actor that stashes all messages until a continuation of the > future sends me another message. But that requires a special mailbox and the > actor actually reacts to each message. I don't know if there are any > performance concerns here, but it would look cleaner if the actor could > logically return a Future from receive and the dispatcher would understand > that. The idea with actors is that they shall remain responsive whenever possible. Another way to look at it is that the internal queue (or stash) should be limited, and when it overflows you might want to send a negative reply right away. For that the actor needs to be runnable while the Future executes. > In the other direction, we have the ask pattern with its known shortcomings > (can't receive more than one message, creating an actor per message can be > expensive). It would be nice to send the actor a message + a promise it can > complete, but with support for transparent remoting, perhaps falling back to > the ask pattern's implementation in the remote case. (I'm assuming here that, > for local message sends, creating a Promise is significantly cheaper than > creating an Actor that will only ever receive one message. I may be wrong.) The ask pattern creates a very special PromiseActorRef which is just a wrapped Promise and therefore a lot lighter than even an Actor (which is not exactly heavy as well). > > Maybe the correct answer is it really isn't important enough to optimize and > I should just use stash and pattern.ask everywhere. What do you think? Yes, Confucius says: measure first, and optimize only when the measurement tells you to. Regards, Roland > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
