Thanks Noble, I'll try to reproduce in a test then. Does the rule I've set sound right to you though?
On Wed, Feb 24, 2016, 15:19 Noble Paul <noble.p...@gmail.com> wrote: > Whatever it is , there should be no NPE. could be a bug > > On Wed, Feb 24, 2016 at 6:23 PM, Shai Erera <ser...@gmail.com> wrote: > > Hi > > > > I wanted to try out the (relatively) new replica placement strategy and > how > > it plays with shard splitting. So I set up a 4-node cluster, created a > > collection with 1 shard and 2 replicas (each created on a different) > node. > > > > When I issue a SPLITSHARD command (without any rules set on the > collection), > > the split finishes successfully and the state of the cluster is: > > > > n1: s1_r1 (INACTIVE), s1_0_r1, s1_1_r1 > > n2: s1_r2 (INACTIVE), s1_0_r2 > > n3: s1_1_r2 > > n4: empty > > > > So far as expected, since the shard splitting occurred on n1, the two sub > > shards were created there, and then Solr filled the missing replicas on > > nodes 2 and 3. Also the source shard s1 was set to INACTIVE and I did not > > delete it (in the test). > > > > Then I tried the same, curious if I set the right rule, one of the > > sub-shards' replicas will move to the 4th node, so I end up w/ a > "balanced" > > cluster. So I created the collection with the rule: > > "shard:**,replica:<2,node:*", which per the ref guide says that I should > end > > with no more than one replica per shard on every node. Per my > understanding, > > I should end up with either 2 nodes each holding one replica of each > shard, > > 3 nodes holding a mixture of replicas or 4 nodes each holds exactly one > > replica. > > > > However, while observing the cluster status I noticed that the two > created > > sub-shards are marked as ACTIVE and leader, while the two others are > marked > > in DOWN. Turning on INFO logging I found this: > > > > Caused by: java.lang.NullPointerException at > > > org.apache.solr.cloud.rule.Rule.getNumberOfNodesWithSameTagVal(Rule.java:168) > > at org.apache.solr.cloud.rule.Rule.tryAssignNodeToShard(Rule.java:130) at > > > org.apache.solr.cloud.rule.ReplicaAssigner.tryAPermutationOfRules(ReplicaAssigner.java:252) > > at > > > org.apache.solr.cloud.rule.ReplicaAssigner.tryAllPermutations(ReplicaAssigner.java:203) > > at > > > org.apache.solr.cloud.rule.ReplicaAssigner.getNodeMappings0(ReplicaAssigner.java:174) > > at > > > org.apache.solr.cloud.rule.ReplicaAssigner.getNodeMappings(ReplicaAssigner.java:135) > > at org.apache.solr.cloud.Assign.getNodesViaRules(Assign.java:211) at > > org.apache.solr.cloud.Assign.getNodesForNewReplicas(Assign.java:179) at > > > org.apache.solr.cloud.OverseerCollectionMessageHandler.addReplica(OverseerCollectionMessageHandler.java:2204) > > at > > > org.apache.solr.cloud.OverseerCollectionMessageHandler.splitShard(OverseerCollectionMessageHandler.java:1212) > > > > I also tried with the rule "replica:<2,node:*" which yielded the same > NPE. I > > run on 5.4.1 and I couldn't find if this is something that was fixed in > > 5.5.0/master already. So the question is -- is this a bug or did I > > misconfigure the rule? > > > > And as a side question, is there any rule which I can configure so that > the > > split shards are distributed evenly in the cluster? Or currently > SPLITSHARD > > will always result in the created shards existing on the origin node, and > > it's my responsibility to move them elsewhere? > > > > Shai > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
