[
https://issues.apache.org/jira/browse/SOLR-14340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062755#comment-17062755
]
David Smiley commented on SOLR-14340:
-------------------------------------
I think this question gets to the semantics of what CLUSTERSTATUS's job is. I
think it should reflect back what is there – what's in DocCollection, aliases,
what the collection's config set name is. That's it. I don't think it should
be a deeper health check and thus shouldn't be reporting errors. I looked at
SOLR-10720 and I think the root cause is actually _this issue_ – ZkStateReader
is validating the config when it should simply return its name. If there is no
config name, we can even return null and document this and inspect the callers.
Once SOLR-14341 happens, the config name will be in the DocCollection and thus
won't even be null.
> ZkStateReader.readConfigName is doing too much work
> ---------------------------------------------------
>
> Key: SOLR-14340
> URL: https://issues.apache.org/jira/browse/SOLR-14340
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
>
> ZkStateReader.readConfigName reads the configSet name given a collection name
> parameter. Simple. It's doing too much work to do this though. First it's
> calling zkClient.exists() which is redundant given that we then call getData
> will will detect if it doesn't exist. Then we validate that the config path
> exists. But I don't think that should be verified on read, only on write.
> This method is a hotspot for nodes with lots of cores, proven out with
> profiling.
> Ideally the configSet name ought to be moved to state.json which is where all
> the other collection metadata is and is thus already read by most spots that
> want to read the configSet name. That would speed things up further and
> generally simplify things as well. That can happen on a follow-on issue, I
> think.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
