Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 12 Sep 2016 13:11:20 +0000 (UTC)
From: "Tim Owen (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.13004292.1473685828000.547283.1473685880493@Atlassian.JIRA>
In-Reply-To: <JIRA.13004292.1473685828000@Atlassian.JIRA>
References: <JIRA.13004292.1473685828000@Atlassian.JIRA> <JIRA.13004292.1473685828910@arcas>
Subject: [jira] [Created] (SOLR-9503) NPE in Replica Placement Rules when
 using Overseer Role with other rules
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 12 Sep 2016 13:11:22 -0000

Tim Owen created SOLR-9503:
------------------------------

             Summary: NPE in Replica Placement Rules when using Overseer Role with other rules
                 Key: SOLR-9503
                 URL: https://issues.apache.org/jira/browse/SOLR-9503
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
          Components: Rules, SolrCloud
    Affects Versions: 6.2, master (7.0)
            Reporter: Tim Owen


The overseer role introduced in SOLR-9251 works well if there's only a single Rule for replica placement e.g. {code}rule=role:!overseer{code} but when combined with another rule, e.g. {code}rule=role:!overseer&rule=host:*,shard:*,replica:<2{code} it can result in a NullPointerException (in Rule.tryAssignNodeToShard)

This happens because the code builds up a nodeVsTags map, but it only has entries for nodes that have values for *all* tags used among the rules. This means not enough information is available to other rules when they are being checked during replica assignment. In the example rules above, if we have a cluster of 12 nodes and only 3 are given the Overseer role, the others do not have any entry in the nodeVsTags map because they only have the host tag value and not the role tag value.

Looking at the code in ReplicaAssigner.getTagsForNodes, it is explicitly only keeping entries that fulfil the constraint of having values for all tags used in the rules. Possibly this constraint was suitable when rules were originally introduced, but the Role tag (used for Overseers) is unlikely to be present for all nodes in the cluster, and similarly for sysprop tags which may or not be set for a node.

My patch removes this constraint, so the nodeVsTags map contains everything known about all nodes, even if they have no value for a given tag. This allows the rule combination above to work, and doesn't appear to cause any problems with the code paths that use the nodeVsTags map. They handle null values quite well, and the tests pass.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org