On Fri, Feb 28, 2014 at 10:58 AM, Martin Senne <[email protected]>wrote:
> Hi all, > > first, thanks for the very constructive answers. > > @Roland: As you pointed out, the future context is the most crucial part > when distributing futures. I followed your suggestion and had a deep look > into spores ( http://docs.scala-lang.org/sips/pending/spores.html ), > which seem to perfectly fit the requirements. Unfortunately, I was not able > to gain information about the current status of SIP-21. Is it somewhere > available? > > @Endre and Roland: Concerning remote class loading: I do not see the > point, of why one wants to do that. Is the assumption "code is already > distributed to all nodes" not valid? Asked the other way round: Under which > circumstances does one need to distribute code as well? > > @Viktor: Do you refer to "Idiomatic Akka (! / tell) versus Non-blocking > Akka Futures ( ? / ask)" ( > https://groups.google.com/forum/?hl=de#!searchin/akka-user/e$20programming$20language/akka-user/GlMq6J4ZlAc/sDtayngFKMwJ) > ? The discussion done there was very helpful in that it covers the > problems of different "execution context"s with the ask pattern when > completing the future. Thanks! > Great! You can also search the archives for "promise pipelining" for more discussion on the topic. > > For this first "PoC" of distributed futures I'll neglect > > - code distribution > - retrieval of available remote nodes > - distribution strategy. > > I'll try and start with the ExecutionContext. Do you know of any > supplementary material for "creating a custom ExecutionContext"? > > Looking forward to hearing your comments, > > Martin > > > 2014-02-27 10:55 GMT+01:00 √iktor Ҡlang <[email protected]>: > > There was a discussion related the to E programming language on the >> mailing list not that long ago that might be of interest for this topic. >> >> >> On Thu, Feb 27, 2014 at 10:41 AM, Akka Team <[email protected]>wrote: >> >>> 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. >>> >> >> >> >> -- >> Cheers, >> √ >> >> * ——————— **Viktor Klang* >> *Chief Architect - **Typesafe <http://www.typesafe.com/>* >> >> Twitter: @viktorklang >> >> -- >> >>>>>>>>>> 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. >> > > -- > >>>>>>>>>> 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. > -- Cheers, √ *———————**Viktor Klang* *Chief Architect - **Typesafe <http://www.typesafe.com/>* Twitter: @viktorklang -- >>>>>>>>>> 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.
