[
https://issues.apache.org/jira/browse/SOLR-14340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-14340.
---------------------------------
Fix Version/s: 8.6
Resolution: Fixed
Thanks [~matmarie] for your 2nd contribution! (Mathieu is a close colleague of
mine).
We'll see who has time to move the config name to state.json where it ought to
have been all along. I don't have time for that in the immediate future.
> 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
> Fix For: 8.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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
