You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/07/02 15:32:00 UTC

[jira] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org