Hi Martin, 5 mar 2014 kl. 19:10 skrev Martin Senne <[email protected]>:
> Hi *, > > after some more hours of hAKKing: I got distributed futures working in a > cluster of 3 nodes ;) Happy!!!! :-) > Scenario for test: one service node, two worker nodes. A distributed futures > (dfuture) is send to > an freshly created instance of ActorCompletedPromiseRunnable, > forwarded to an service actor (acting as a router), > transferred (body) to one of the worker nodes (via round robin), > calculated and > the result finally returned to the ActorCompletedPromiseRunnable in order to > complete the promise. Yes, this is basically how it should work. Your approach naturally has the downside of creating many actors at the top level using system.actorOf; this could be fixed by requiring an ActorRefFactory (which could then also be an ActorContext) and instantiating actors as children of the logical caller (i.e. the actor who creates the dfuture). On the other hand the ask pattern already does this, and it does so in an optimized fashion as well, see here. This means that your part of the work could be collapsed into just sending the computation to the router/worker using “ask()”, which returns a Future[Any] that you can cast to Future[T] based on your knowledge of the processing that will happen. Unfortunately I think you are right that this cannot be packaged as an ExecutionContext, because the tasks are scheduled only for their side-effects, which won’t work on a different JVM. This means that you’ll need to add some of the combinators (especially flatMap) on your dfuture directly. > What I would like to know: > > What is your suggested approach to write tests in cluster? Please take a look at the multi-jvm tests in the cluster sources. > What is the desired platform for code discussions / reviews? Forum? Gist? You could create a repo on github and use pull requests for presentation (which allows people to comment nicely on the changes; commenting on the code itself is unfortunately not supported). > Next steps: > Cluster tests > Performance tests Yes, it will be interesting to see what the overhead is and which use-cases would benefit from this kind of distribution. Regards, Roland > Cheers, > > Martin > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> 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/groups/opt_out. 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://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
