Hi Glenn, One other reason to use a separate ActorSystem would be if you actually launch it in a second JVM, even though both systems are local. This might be useful in cases when you want to delegate dangerous jobs to the secondary system so even if it dies with OOM you still have the primary alive. Not a very common use case, but can be useful.
-Endre On Wed, Aug 27, 2014 at 1:09 PM, Glenn Grant <[email protected]> wrote: > Hey Prakhyat, > > By that if was referring to the 'untrusted' mode in remoting security (or > whatever it's actually called) > > - G > > Sent from my iPhone > > On 27 Aug 2014, at 7:42 pm, Prakhyat Mallikarjun <[email protected]> > wrote: > > Hi Glen, > > Was going through your post did not understand what you meant > by 'protected mode'? > > -Prakhyat M M > > On Friday, 22 August 2014 08:33:07 UTC+5:30, Glenn / devalias wrote: >> >> Heya, >> >> So, most/pretty much everything I read says ActorSystems are heavyweight, >> and you should only use one unless you have a 'really good reason' to use >> more than one since they are 'heavy'. >> >> I was wondering >> >> - Just how heavy is an ActorSystem? >> - Conceivably how many could you run in a JVM and how much >> memory/threads/etc would it require? >> - Is there a commonly known 'weight' for an ActorSystem? >> >> I've also been wondering about what would be a 'really good reason' to >> have multiple ActorSystems. The one topic that particularly came to mind >> was an overall 'network' of 'nodes' (though not necessarily in the >> clustered sense) where each node needs to maintain it's own sandboxed >> ActorSystem to prevent 'crosstalk' from another ActorSystem (except by well >> defined channels using remoting, receptionist, 'protected mode', and all >> the other fun things Akka provides in that regard) >> >> Conceivably this model COULD be put into a conventional model (single >> ActorSystem + potentially a few more/cluster setup for remote >> deployment/etc), but then it seems like you would have to manually >> re-implement a lot of protections to attempt to isolate each 'node' from >> affecting one another. (eg context.parent.parent.parent, >> context.select(../../../../../../../*) or context.system.shutdown, etc) >> >> Aside from the 'heaviness' of running these multiple ActorSystems, it >> raises a few more questions. >> >> - In the 'normal actor' model, we can make use of remote deployment >> to easily farm these 'nodes' out to remote servers, possibly even >> lazily/on >> demand (not starting them till required), though it would seem there is no >> way to remotely 'deploy' an ActorSystem from within Akka (since it would >> need to 'deploy' into an ActorSystem) >> - Can an ActorSystem be created 'inside' another ActorSystem (eg. an >> Actor creates a new ActorSystem) If so, how does this effect the lifecycle >> of the 'inner' ActorSystem? Will it die when the outer ActorSystem dies? >> - Is clustering designed to allow arbitrary potentially untrusted >> ActorSystems to communicate? I would think it doesn't really fit the >> model, >> since it's possible that a rogue system in a cluster could break/interfere >> with gossip/etc. >> - If clustering isn't the answer, is there a 'best practice' for >> disparate potentially untrusted ActorSystems to communicate/interact? >> >> >> Lot's of ponderings and mind dumping here, so hopefully it makes enough >> sense to be followed. >> >> Looking forward to your thoughts/insights! :) >> >> - Glenn / devalias >> >> >> >> -- > >>>>>>>>>> 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 a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/Dh55Mjv_vOU/unsubscribe. > To unsubscribe from this group and all its topics, 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. > > -- > >>>>>>>>>> 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. > -- 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://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.
