What I do is use a central sql database and have active nodes periodically update it with their status. New nodes joining the cluster just query that to get a node to join against. The notion of a 'primary' seed node doesn't really exist in akka, seeds are not any different then regular nodes.
This has proven to work reliably. With transactions I have atomic updates on the data that represents the cluster status. At some point you must use some type of external service/data source to manage your nodes. When things to wrong and you have network partitions and such, an individual cluster has no way of just fixing things on it's own without outside assistance. You can bake this logic into your nodes so they can self manage the situation, or you can use external tools. But one way or another you need a layer of logic that sits outside the cluster to handle this well. Chris On Friday, November 7, 2014 3:11:21 PM UTC-8, jxtps wrote: > > There > <https://groups.google.com/forum/#!searchin/akka-user/ec2$20seed$20nodes/akka-user/lBcl3WgEM_0/mocdn8-jmXsJ> > are > a > <https://groups.google.com/forum/#!searchin/akka-user/ec2$20seed$20nodes/akka-user/_1oc9aEfEJw/zye9BSVKFccJ> > > number > <https://groups.google.com/forum/#!searchin/akka-user/ec2$20seed$20nodes/akka-user/-rwF3t_OF4I/soogf_uHLgsJ> > > of threads > <https://groups.google.com/forum/#!searchin/akka-user/ec2$20seed$20nodes/akka-user/rKS9jnaFvv8/_1ulsZQvfX0J> > > on how to deploy an akka cluster on ec2, and it seems straightforward to > establish the list of potential members of a cluster (e.g. get the members > in an auto scaling group, or a security group, or whatever), and these can > be sensibly ordered (e.g. by launch time with IP being a tie-breaker) such > that all hosts can agree on which one should be the "primary" seed node. > Cluster(system).joinSeedNodes(primary, > *[hosts other than current one]*) can then be used to get the cluster > going. So far so good. > > However, when the primary starts the application (after first launch, code > deploy, or reboot), it has no idea if there's already a cluster running, or > if it should indeed start a new cluster (keep in mind that a cluster may > recently have been running, but it may have been shut down in the last 30 > seconds so that helpful information you wrote to disk before restarting may > be terribly out of date). > > *Assuming there is no network partitioning*, i > *s Cluster(system).joinSeedNodes(myself, host2, host3, host4, ...) smart > enough to check for and join an existing cluster if the other hosts are > already running it, or does it always start a new one if the current > machine is the first entry?* > Previous answers > <https://groups.google.com/d/msg/akka-user/rKS9jnaFvv8/lwW8pzLJ5xEJ> have > left this precise point a little ambiguous. > > If not, what are some best practices for how to have the intended seed > node start a new cluster if the cluster isn't running, but be smart enough > to join the existing cluster if it's already there? > > *I do not want to use any external dependencies (= zookeeper) other than > the AWS APIs from which I can get a canonical list of all the relevant > hosts. * > > > -- >>>>>>>>>> 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.
