[
https://issues.apache.org/jira/browse/SOLR-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825689#comment-16825689
]
Gus Heck commented on SOLR-13418:
---------------------------------
[~tomasflobbe], there's a patch in SOLR-13420 that demonstrates the use case
and improves the synchronization somewhat. I haven't been able to convince
myself that there are any ways in which collection properties are likely to be
updated frequently, and mostly
org.apache.solr.common.cloud.ZkStateReader#createClusterStateWatchersAndUpdate()
is called when new objects like ZK or overseer update threads are created (or
if the overseer hits an error, and calls
forciblyRefreshAllClusterStateSlow()...)
If you think we need to do something like keep a map of lock objects keyed by
collection to further reduce synchronization or you have another cleaner idea
than that we can re-open this.
> ZkStateReader.PropsWatcher synchronizes on a string value & doesn't track zk
> version
> ------------------------------------------------------------------------------------
>
> Key: SOLR-13418
> URL: https://issues.apache.org/jira/browse/SOLR-13418
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 8.0, master (9.0)
> Reporter: Gus Heck
> Assignee: Gus Heck
> Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> While contemplating adding better caching to collection properties to avoid
> repeated calls to ZK from code that wishes to consult collection properties,
> I noticed that the existing PropsWatcher class is synchronizing on a string
> value for the name of a collection. Synchronizing on strings is bad practice,
> given that you never know if the string might have been interned, and
> therefore someone else might also synchronizing on the same object without
> your knowledge creating contention or even deadlocks. Also this code doesn't
> seem to be doing anything to check ZK version information, so it seems
> possible that out of order processing by threads could wind up caching out of
> date data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
