[
https://issues.apache.org/jira/browse/SOLR-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227546#comment-17227546
]
Bruno Roustant commented on SOLR-14975:
---------------------------------------
I added a PR.
I believe descriptors are superset of loaded cores. And also permanent cores
are distinct from transient cores.
I simplified the logic to create lists based on distinct sets. And I added
assertions to verify the sets are indeed distincts. All tests passed.
> Optimize CoreContainer.getAllCoreNames and getLoadedCoreNames
> --------------------------------------------------------------
>
> Key: SOLR-14975
> URL: https://issues.apache.org/jira/browse/SOLR-14975
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The methods CoreContainer.getAllCoreNames and getLoadedCoreNames hold a lock
> while they grab core names to put into a TreeSet. When there are *many*
> cores, this delay is noticeable. Holding this lock effectively blocks
> queries since queries lookup a core; so it's critically important that these
> methods are *fast*. The tragedy here is that some callers merely want to
> know if a particular name is in the set, or what the aggregated size is.
> Some callers want to iterate the names but don't really care what the
> iteration order is.
> I propose that some callers of these two methods find suitable alternatives,
> like getCoreDescriptor to check for null. And I propose that these methods
> return a HashSet -- no order. If the caller wants it sorted, it can do so
> itself.
--
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
