[
https://issues.apache.org/jira/browse/SOLR-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17223975#comment-17223975
]
Erick Erickson commented on SOLR-14975:
---------------------------------------
Yeah, these look like they're over-used. I'm not certain though that checking
getCoreDescriptor is sufficient in all cases.
SolrCores.getAllCoreNames for instance gets names from SolrCores, the
TransientCacheHandler _and_ residentDescriptors. Can we guarantee that the
names in residentDescriptors is a superset of cores.keySet and similarly for
getTransientCacheHandler().getCoreDescriptor .vs.
getTransientCacheHandler().getAllCorenames()?
BTW, SolrCores.getCoreDescriptors() (note the 's') also has the issue, although
it may not be called very often.
I certainly do remember that getting that all to work when I made
transientCacheHandler pluggable was a bear. That said, the code has evolved
from that long-ago date. I'm not defending the current implementation, just
sayin' that it may be...less pleasant to change than it appears at first glance.
I'm not sure queries block on these. CoreContainer.getCore(some_core) doesn't
look like it calls these on a quick glance. Is there someplace else they're
called for queries? NOTE: it's Friday night so I'm not too sharp and it may be
obvious.
All that said, assembling these lists is expensive and anything we can do to
cut down on calling them is a fine idea. They may well be being used because
they were a pre-existing call without understanding the costs. I do wonder if
that's the case there's some mechanism to keep them from being used
inappropriately in the future.
Of course if whoever picks this up is really ambitious, much of this could be
re-thought...
> 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
>
> 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
