[
https://issues.apache.org/jira/browse/SOLR-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17230421#comment-17230421
]
ASF subversion and git services commented on SOLR-14975:
--------------------------------------------------------
Commit c53f0630169c535f24534a1b1333cbebdfc7ea2f in lucene-solr's branch
refs/heads/branch_8x from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c53f063 ]
SOLR-14975: Optimize CoreContainer.getAllCoreNames and getLoadedCoreNames.
Also optimize getCoreDescriptors.
Closes #2066
> 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: 4.5h
> 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
