[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146961#comment-17146961
]
Erick Erickson commented on SOLR-10742:
---------------------------------------
Not quite sure what you're thinking might be removed. The call from metrics or
getNamesForCore? The latter is public in CoreContainer unfortunately.
I'm starting to wonder myself what the point of that method is. It's been there
since I made transient cores pluggable. Maybe Andrzej has a clue. If it's OK
for Solr to, say, just use the core name and _not_ report on all the aliases,
perhaps we can just not use it at all in Solr and add some docs about how "if
your custom implementation needs this, make it efficient".
[~ab] Do you know why metrics needs a list of all the aliases a particular core
is referenced under? More to the point, if the call to getNamesForCore in
SolrCore.initializeMetrics just changed to get the name from "this", would that
be bad? It'd certainly be a change but IDK whether it'd be impactful.
> 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
