Glenn, Find my answers below.
Heiko On 22 Aug 2014, at 05:03, Glenn / devalias <[email protected]> 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'. Where did you find that last statement? I'm asking because in order to use Akka actors you need at least one ActorSystem. > > I was wondering > Just how heavy is an ActorSystem? The heaviest part of an actor system is the dispatcher: Each actor system has at least one. The dispatcher essentially is the engine that makes the actors run. In order to do so it needs threads, usually obtained from a thread pool. The default dispatcher by default (default to the power of two) uses a fork-join thread pool with at least 8 threads. There are other shared facilities, some in user space and some internal, e.g. the guardian actors, the event stream, the scheduler, etc. All of these need to be created and started. > Conceivably how many could you run in a JVM and how much memory/threads/etc > would it require? I don't think that heaviness in terms of memory is an issue here. What really matters are the thread pools. As I said, per default an actor system creates a fork-join pool with at least 8 threads. If your application needs to bulkhead certain actors from others, e.g. because some of the actors are doing blocking stuff, you need multiple dispatchers, i.e. multiple thread pools. > 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. One good reason that comes to my mind are tests which are executed in parallel. In my project that's usually the case, I would say that the tests typically create more actor systems at one time than I have cores available, i.e. some 10. Apart from that, I don't think having multiple local actor systems, i.e. in one JVM or on one machine, is a common pattern. If you really want to scale up most efficiently, one actor system with one thread pool configured to the numbers of cores (assuming a blocking factor of zero) should give you the best results. If you then need to further scale, scale out, i.e. create actor systems on remote nodes. > 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? No > 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. There are security features: http://doc.akka.io/docs/akka/2.3.5/scala/remoting.html#Remote_Security > 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 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. -- >>>>>>>>>> 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.
