Hi Luis, On 4 November 2014 at 17:00:35, Luis Medina ([email protected]) wrote:
Hi Björn and Patrik, Thank you very much for the insight. Got a couple more follow up questions: 1. Does the akka.cluster.min-nr-of-members configuration apply to the cluster only when it is first started up or does it continue to stay in effect throughout the cluster's life cycle? The reason I ask is because I'm wondering if it could be used to prevent single nodes that have been auto-downed from starting back up again and forming separate clusters due to the fact that they wouldn't have the minimum number of nodes required for this to happen. It stays in effect in the sense that the leader wont move a joining node to up unless there are at least that many members in the cluster (their state is not taken into account). I don't see how you could guarantee them from forming separate clusters. Just because a node is aut-downed doesn't mean that it is dead. It could be happily living with some friends in their own cluster (no restart required) behind a network partition. 2. Eventually, I want to run an elastic Akka cluster that can change based on the load. In the documentation it says that as a rule of thumb the number of shards in a cluster should be a factor of ten greater than the planned maximum number of nodes. The issue here is that this maximum number of nodes could change dramatically which would make initial calculations for the number of shards inaccurate and would most likely degrade performance or at least not take full advantage of new resources. a. Is there any way of dynamically changing the total number of shards in a cluster through the ShardRegion.MessageExtractor that is used by the ShardRegions so that it can adapt to changes in the cluster's size? Since the mapping between message and shardId must be consistent on all nodes att all times, I don't see how you could change that on the fly with messages being processed. b. Are there any downsides of overestimating the total number of shards that are going to be in a cluster in order to account for any unforeseen growth of the cluster? Initially I'm thinking that there will probably be many shards with single (or very few) entries assigned to each one although I figure that something like a LeastShardAllocationStrategy would be effective at re-balancing the load in this scenario. Also, since a "shard" is really an abstract concept that is actually managed by a ShardRegion (at least by my understanding), if I started out with a small number of nodes in my cluster, these nodes wouldn't really get overloaded with a bunch of instances of these "shards" since entries are created as children of the ShardRegions and there is only one ShardRegion per entry type per node. If you over estimate the number of shards, you will have a number of maps growing unnecessarily large, and also lookup in them could be slowed down, but apart from that I see no problem. I mean what numbers are you talking about here? It's kind of hard to answer without not even a guesstimate about how many nodes you will start with or grow to. B/ Luis -- >>>>>>>>>> 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. -- Björn Antonsson Typesafe – Reactive Apps on the JVM twitter: @bantonsson -- >>>>>>>>>> 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.
