[
https://issues.apache.org/jira/browse/SOLR-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15800758#comment-15800758
]
Noble Paul commented on SOLR-9503:
----------------------------------
[~TimOwen] The fix looks fine. I could commit it if we could add a JUnit
> 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
> Assignee: Noble Paul
> Attachments: SOLR-9503.patch
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
