@Tal Ecxellent answer On Tuesday, 15 March 2016 07:35:10 UTC, Tal Pressman wrote: > > Hi, > > Basically it boils down to which actors should supervise others - if you > want to have a single actor responsible for supervising all the chat rooms > that's fine. Note that this *doesn't* mean that all requests have to be > routed through the supervisor actor. Messages can be sent between any 2 > actors, regardless of their relation in the actor hierarchy. > > Regarding what happens when you make the actor persistent - this shouldn't > change anything. The supervisor is still only responsible for restarting > (or whatever strategy you choose) the child actors, while the > PersistentActor is responsible for recovering its own state when it is > restarted. > > So to answer your "root" question(s): > > 1. It's fine if you want to have a single actor that's in charge of > all the chat room actors. It's also OK to just let them be supervised by > the default user guardian actor, if there is nothing special about their > recovery strategy. > 2. Basically, all you need to communicate with an actor is its > ActorRef. You can either use the built-in ActorSelection to lookup actors > based on their name (possibly with caching), or you can have the > supervisor > actor manage such a cache to lookup the chat room actors. > > Hope this helps, > Tal > > > On Monday, March 14, 2016 at 2:29:53 AM UTC+2, Neale Genereux wrote: >> >> Hello all, >> >> I'm playing around with Akka in conjunction with the Play framework, >> working in Java. I have a reasonable understanding of how the actor system >> works in general, but I need some help wrapping my head around how to set >> up the system efficiently. >> >> Let's take the Chat server example. Let's say my Play server has several >> chat rooms, each identified by an ID. Each chat room has a single actor >> which stores the chat history as state, and handles requests to post new >> messages, forwarding them in turn to all other listeners. It can also >> handle a request to get all previous chat history. My question is: How do >> you setup the actor hierarchy for this system to work efficiently? >> >> My first instinct is to create some sort of chat room supervisor actor >> which will store a map of chat room id's to child actor refs. This >> supervisor can now handle chat room failures, and requests to create or >> remove chat rooms. However, every request to every chat room now has to go >> through this supervisor, creating a bottleneck. >> >> Additionally, if I decide to make my chat room actors persistent, I'm not >> sure whether it is this supervisor's job to recreate those actors after a >> system restart. If not, how can the supervisor get its list of child actors >> back? >> >> I guess my root question is this: >> How do I setup a system which will have many stateful, persistent actors >> of the same type, all identified by a unique id such that: >> 1) Each actor is supervised by an actor which can handle issues with its >> lifecycle >> 2) Clients, such as HTTP requests from the Play framework, can >> efficiently communicate with these actors assuming they have that actor's ID >> >> Thanks for any help you can give me! >> >
-- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
