[
https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146630#comment-17146630
]
Erick Erickson commented on SOLR-10742:
---------------------------------------
[~dsmiley] As you can probably tell, I'm going through a bunch of stuff I've
had in my queue for a while.
This is kind of a sticky wicket to _really_ fix. There's such a loose coupling
of aliases.. There can be several SolrCores, each with a different name that
point to the same underlying core. So any idea of a SolrCore keeping a list of
aliases that point to it would mean updating N SolrCores.
I'm looking at your suggestion of using ReentrantReadWriteLock. It looks
reasonably straightforward except for two things;
The method getModifyLock. Currently it returns an Object, but to work correctly
it needs to return a ReentrantReadWriteLock, a back-compat break. If we leave
it as returning an Object, I can't seem to find what wait() actually does. Wait
on both read and write locks? Wait on just the writeLock which is exclusive
access?
Problem is, that's used over in CoreContainer. What it feels like is that all
the code that uses getModifyLock should obtain the writeLock to have the same
behavior as just getting the locking object in the current code. Unless
ReentrantReadWriteLock takes care of that... researching...
So there are two issues:
1> does the back-compat issue count? AFAIK, there;s only one client that would
be inconvenienced by this and you can talk to them. Can we still return just an
Object? I'm unclear (I'm researching) what happens when you call, say,
synchronized (ReentrantReadWriteLock) really does. I suspect just obtains a
writeLock, which is exclusive.
2> There are several places we wait for changes in the synchronized structures.
It's unclear to me how much savings this would actually make.
Another alternative I'm thinking about is "uninverting" this structure, i.e.
keeping a Map<SolrCore, List<String>>, with the obvious synchronization issues.
That bleeds over into anyone who implements TransientCoreCache having to do
something efficient there, including the default implementation. I looked a
little at the code, and there aren't very many places that actually modify the
cores map, so perhaps keeping an uninverted cache up to date isn't as bad as I
thought.
I'll think some more about this, I don't particularly like any of the
alternatives. WDYT?
> 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
