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 > > create a promise locally > create one local actor (caller) > create one new remote actor on any of the cluster nodes (callee), via round > robin, etc. > send message to callee actor to start computation > ... actor comes eventually to execution ... > 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 > 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 – 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.
