[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150385#comment-17150385
]
Erick Erickson commented on SOLR-10742:
---------------------------------------
I chatted with [~ab] and he doesn't object to removing this call, with the
caveat that third-parties may rely on it.
I propose removing this call from the metrics initialization code and all the
associated calls as they're trappy. If someone really needs to implement this,
they can iterate the lists themselves.
The problem with maintaining a parallel inverted list is that then every
operation that changed the cores list has to traverse all the values of the
inverted list to potentially remove an old entry, which is the same problem in
reverse.
Alternatively we could make a copy of the cores list in getNamesForCore, then
release the lock and return the results from the copy. I don't _know_ that's
bad, on a brief experiment I think it took < 10ms to clone a 10K list. It would
be relatively simple to keep a timestamp that's the last time the cores list
was modified and only do the copy when that timestamp changed. But that feels
like the tail wagging the dog for code noboby has spoken up for and is marked
experimental anyway. Plus, that list would be changing all the time on startup
with loading lots of cores and I have no evidence it's being used any other
time.
So absent objections, I'm going to remove getNamesForCores and all associated
code in the next couple of days.
> 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
