[
https://issues.apache.org/jira/browse/SOLR-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16826635#comment-16826635
]
Tomás Fernández Löbbe commented on SOLR-13418:
----------------------------------------------
The intended use of Collection properties is similar to Cluster Properties, to
transmit simple configuration to components of collections (in fact, a common
pattern we use is to consider cluster properties as default values when a
collection property is not present). Since not every node hosts every
collection, Collection Properties are implemented slightly different, using
watchers (and that’s the reason a simple call to
{{getCollectionProperties(collection)}} doesn’t cache the result). Components
can set watchers on collection properties and adapt/reconfigure after changes
(i.e. suppose you have a component to apply backpressure in queries, you can
change the amount of QPS that the component will allow, without having to
reload your collection).
I don’t know much about TRA, but looking at your patch, can’t you make the
URPFactory register a watcher (by calling {{registerCollectionPropsWatcher}})
and cache the properties locally? That’s the intended use of the watchers.
Then, the URP would just query that map that the factory keeps locally (can be
passed to the URP on constructor or whatever way you prefer to do that.
> 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
