Another link that might help understand how to use Akka Cluster Sharding: https://github.com/hseeberger/reactive-flows/commit/e0fe29434592e591b8579b43c6c082ad6137e44c <https://github.com/hseeberger/reactive-flows/commit/e0fe29434592e591b8579b43c6c082ad6137e44c>
Heiko > On 14 Nov 2014, at 12:03, Richard Bowker <[email protected]> > wrote: > > 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/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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 > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <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/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <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.
