On Mon, Feb 17, 2014 at 5:58 PM, Andrea Salvadore < [email protected]> wrote:
> Hi Patrick, thanks for your answer. > > What is the read actors doing? Is the state of the write actor > replicated to the read actors, or what is the purpose? > > Yes, my initial solution had read and write actors sharing the state via > messages. I've changed the solution slightly and now I am sharing state > using Agents. > The last thing I need to figure out is how to keep other nodes up-to-date > when using agents. > Agents are local only. > Given the writes are really low there are option but so far I am thinking > to use distributed pub-sub. > ok, that might work. An alternative, since you are already using eventsourced, is be to switch to Akka persistence in 2.3.0-RC3 and its Persistent Views <http://doc.akka.io/docs/akka/2.3.0-RC3/scala/persistence.html#Views>. /Patrik > Thanks for your help, it clarifies things. > > > On Monday, 17 February 2014 12:05:01 UTC, Patrik Nordwall wrote: > >> Hi, >> >> >> On Sat, Feb 15, 2014 at 11:47 AM, Andrea Salvadore <[email protected] >> > wrote: >> >>> Hi all, >>> I am writing an application using play and akka. I would like to >>> understand a bit better how the cluster singleton and the router actually >>> work. >>> >>> I have multiple instances of the same play application running behind a >>> load balancer (say 4 instances on 2 boxes). The application is simply >>> manipulating json and using eventsourced to persist deltas. >>> What I would like is to have a single write actor and a number (say 8) >>> of read actors. I read about the cluster singleton and the router using >>> remote actors. >>> >> >> What is the read actors doing? Is the state of the write actor replicated >> to the read actors, or what is the purpose? >> >> >>> >>> It seem to be what I want to use but I am trying to understand if this >>> would actually work. >>> >>> When the first play app starts it creates the write actor and the router >>> with 8 read actors. When the next one starts and joins the cluster, what is >>> it going to happen? >>> >> >> For the write actor you use the ClusterSingletonManager, I guess. It will >> create the write actor instance on the oldest cluster member, and nowhere >> else. >> >> >>> Reading the docs I understand the write actor is simply going to point >>> back to the first instance write actor, is that correct? >>> >> >> ClusterSingletonManager is not pointing anywhere. Its responsibility is >> to create the one and only singleton actor instance. To send messages to >> the singleton actor you have to keep track of where this singleton actor is >> running, as described in the docs. >> >> >>> What if the second instance cannot join the cluster for a few seconds >>> and the write actor gets created in the mean time? Will it still get >>> changed to point to the write actor on the first instance after joining the >>> cluster? >>> >> >> I think I have covered that. >> >> >>> What about the read actors? Will every instance try to create the read >>> actors meaning that I will end up with 8 (reader pool size) x 4 (number of >>> instances) read actors? Or maybe the cluster is smart enough to reconfigure >>> itself when a new node joins or leaves the cluster? >>> >> >> For routers you have two options: >> >> 1. Group - router that sends messages to the specified path. The >> routees can be shared between routers running on different nodes in the >> cluster. >> >> 2. Pool - router that creates routees as child actors and deploys >> them on remote nodes. Each router will have its own routee instances. For >> example, if you start a router on 3 nodes in a 10 nodes cluster you will >> have 30 routee actors in total if the router is configured to use one >> inctance per node. The routees created by the different routers will not >> be >> shared between the routers. >> >> Cheers, >> Patrik >> >> >>> >>> Thanks a lot for your help >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> >> >> -- >> >> Patrik Nordwall >> Typesafe <http://typesafe.com/> - Reactive apps on the JVM >> Twitter: @patriknw >> >> -- > >>>>>>>>>> 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
