[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147040#comment-17147040
]
Erick Erickson commented on SOLR-10742:
---------------------------------------
I played around a bit with making a wrapper class that maintains a parallel
map<core, set<names>>. That reduces the getNamesForCore to
{code}
Set<String> ret = namesForCore.get(core);
return ret == null ? Collections.emptySet() : ret;
{code}
Which should be much more efficient at the cost that every modification of the
cores map requires that we also maintain the parallel "inverted" structure
Map<SolrCore>, Set<String>>. I don't think it'd be much extra work in terms of
CPU though.
It's technically do-able, but... it adds complexity for something I'm still
unsure is needed. The method in question is marked Experimental so could
theoretically be removed without violating any contracts.
It doesn't even break back-compat. If anyone is implementing their own
TransientSolrCoreCache with a LinkedHashMap, they'd have to make a small code
change to automatically get this optimization. If they didn't make the change,
it would continue to work as before.
If they're using something other than LinkedHashMap, they'd have to implement
something similar in their plugin.
I haven't yet written tests for it, all I'm doing here is getting a feel for
what it would take. And I really don't like adding the complexity.
I'll wait for Andrzej to weigh in about whether we can do something else here
before pursuing.
> SolrCores.getNamesForCore is quite inefficient and blocks other core
> operations
> -------------------------------------------------------------------------------
>
> Key: SOLR-10742
> URL: https://issues.apache.org/jira/browse/SOLR-10742
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> SolrCores.getNamesForCore iterates through all the cores to find all the
> aliases to this core. It does this in a synchronized block which blocks other
> core operations.
> For installations with many cores this can be a performance issue. I'm not
> sure it makes sense to do it this way anyway, perhaps SolrCore should have a
> list of its current aliases and we can be more efficient about this? Or
> otherwise get this information in a less heavy-weight fashion?
> I'm assigning this to myself to keep track of it, but anyone who wants to
> grab it please feel free.
--
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
