Hi Martin, As Roland pointed out it is possible especially if you have the corresponding classes available on all nodes. On the other hand I think the preferred way is to use actors whenever it is possible instead of futures. If you still need the result as a Future for some reason you can still fall back to the ask pattern.
-Endre On Thu, Feb 27, 2014 at 8:10 AM, Roland Kuhn <[email protected]> wrote: > Hallo Martin, > > you can certainly create an ExecutionContext which is constructed from an > ActorContext (to do the actor creation and remote deployment, and also to > access the Cluster extension for finding out about possible destination > nodes) and which does what you describe. If the work to be performed is > worth the overhead of going over the network then this is a quite nifty > idea, actually. > > The main problem you will encounter is that you need to ascertain that the > function you send over the network is serializable (including all the > context it captures--whether it needs that or not) and that the > corresponding class files are available on the remote nodes as well. The > former will probably get you interested in Spores (SIP-21) and the latter > might lead you into the abyss that is called remote class loading (don't go > there if you have a choice). > > Regards, > > Roland > > 26 feb 2014 kl. 16:02 skrev Martin Senne <[email protected]>: > > Hi *, > > recently and while browsing code and investigating how the ask pattern for > actors is implemented, the question "Is it reasonable and possible to > execute futures on actors on distributed nodes of an Akka cluster" came to > my mind. Expressed differently: Can we automatically distribute work, > futures do, across an Akka cluster. > > Is there already a solution, which I have overseen? > > > *Suggestions: Steps to execute a future on an remote node* > > > 1. create a promise locally > 2. create one local actor (caller) > 3. create one new remote actor on any of the cluster nodes (callee), > via round robin, etc. > 4. send message to callee actor to start computation > 5. ... actor comes eventually to execution ... > 6. on completion of the computation, callee sends back > - ether a success message (containing the result of the future > computation) or > - a failure message (containg the Exception) to the caller > 7. on receive of either success or failure message, the caller puts > the result into the promise > > Does this approach seem valid? > > Within step 3 the "automatism" comes into play. Questions to be answered: > Where is the remote actor created? Which strategy does one choose? > Nevertheless, the user should not be bothered with these details. Instead, > the user should just configure which remote nodes form the cluster and are > available to execute work. > > > *Where to start ?* > > On the one hand, a future comes to execution (wrapped as Runnable) via the > execute method of an ExecutionContext. If one sets a different (implicit) > ExecutionContext, this behavior can be changed. > On the other hand the implementation in scala.concurrent.impl.Future and > scala.concurrent.impl.Future.PromiseCompletingRunnable could allow a > different approach. > > What is a reasonable starting point? > > > Looking forward to hearing your comments and ideas, > > 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 <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://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. > -- Akka Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- >>>>>>>>>> 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.
