[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086403#comment-16086403
]
David Smiley commented on SOLR-10742:
-------------------------------------
I think catching ConcurrentModificationExceptions is a bad idea; I'm at least
very weary!
Ideally, SolrCores.cores could become a ConcurrentHashMap and then any
pure-read operations needn't mess with explicit locks. However this might not
be possible depending on if there are any mutations of the map that require a
set of operations to appear atomically. For example the swap operation may be
an issue or not; hard to say. Is it okay if we momentarily have one of the
cores to be swapped be inaccessible while the other core is accessble from both
names? Perhaps I guess. But I see we also have a parallel map of core
descriptors "residentDesciptors" var (?). If so then yuck...
Failing that, use ReentrantReadWriteLock. At least this way we only block
writes. The read overhead won't' be as cheap as ConcurrentHashMap but it
should be fine.
As an aside I'm suspicious and confused of the relationship between
CoreContainer and SolrCores, and CoreDescriptors too. CC is doing multiple
operations on SolrCores (e.g. remove then add for a rename core) that seems odd
to me -- like maybe SolrCores should have this method so it's atomic?
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
>
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
