[
https://issues.apache.org/jira/browse/SOLR-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824723#comment-16824723
]
Gus Heck commented on SOLR-13418:
---------------------------------
I'd say it's acknowleged, I waffled on the possible need to find a more fine
grained solution. The upcoming use case is SOLR-13420 which will want to
consult collection properties on each update request, and certainly we won't
want to consult zookeeper directly each time for that. (I also plan to fiddle
with the synch in getCollectionsProperties() to lock less agressively there (a
double check probably). If you have insight as to how collection properties
have been used (outside of the tests) for other work I'd love to hear it. I
couldn't find anywhere that watchers are registered or
getCollectionProperties() is called in the code base so I would guess that
(until SOLR-13420) the only uses are in custom code, or by external systems via
the REST api....
> 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
