I agree, this sounds like a good fit: this link helped me to understand what to do
https://github.com/ktoso/akkamazing/commits/cluster-sharding-steps-ktoso On Thursday, November 13, 2014 11:31:59 AM UTC, Martynas Mickevičius wrote: > > Hi Anders, > > it seems that cluster sharding fits the bill here. Especially when in your > current setup you send messages to children based on an ID of the event > which is exactly what sharding by entity ID does. > > Now say you have a cluster of nodes and use cluster sharding. If you > remove one node from the cluster the coordinator will rebalance the sharded > entities to the remaining nodes. Same happens when new node joins the > cluster. A predicate upon which fulfillment rebalance is started is defined > in the shard allocation strategy. > > You can also use PersistentActors If you want to recover state when > sharded entities are moved to different nodes. > > On Mon, Nov 10, 2014 at 12:48 PM, Anders Båtstrand <[email protected] > <javascript:>> wrote: > >> Dear group >> >> In a project where performance is not an issue (yet, and possibly never), >> I am thinking about the following cold-standy solution to enable us to >> restart nodes without loosing state: >> >> One node is running with Persistent Actors saving to a database. When >> that node goes down, the other node is started manually, and reading all >> events from the database it gets in the same state. >> >> The problem with this is that we have to do something manually (start the >> new server), and that we are unavailable in the meantime (for instance for >> a GUI). >> >> What is the next step, to have both nodes running at the same time, and >> not appear down to the clients? Is it to have two (or more) nodes running >> in a cluster, with all actors created as singletons? >> >> We use a pattern where events we receive (over SOAP) are sent to a >> parent actor, which forwards to children based on an ID in the event. If >> the ID is unkown, the parent actor creates a new child. >> The children builds up state based on the events, and publishes other >> events based on this state. As I imagine it, the parent actor would be a >> singleton, creating all the children on the same node... That way, starting >> up the parent actor on an already running Akka instance would be pretty >> fast, and reading from the same database it would get in the same state. >> ClusterSingletonProxy >> stashes away messages during this process, so we don't loose requests. >> >> The doc, however, warns against the singleton pattern ("Using a singleton >> should not be the first design choice"), and I am wondering what the >> alternative is for my scenario. >> >> Best regards, >> >> Anders Båtstrand >> >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Martynas Mickevičius > Typesafe <http://typesafe.com/> – Reactive > <http://www.reactivemanifesto.org/> Apps on the JVM > -- >>>>>>>>>> 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.
