[
https://issues.apache.org/jira/browse/SOLR-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827001#comment-16827001
]
Gus Heck commented on SOLR-13418:
---------------------------------
Routed Aliases conditionally wrap DistributedUpdateRequestProcessor if the
request is to a RoutedAlias. The test for this is currently to check a core
property, and this check happens for every update in solr (because at that
point it's not know if it's a routed alias or not). I'm looking to move this
check to use it to a collection property because this is better for testing,
more flexible for future features and makes more sense logically. There would
be no valid case where one core in a collection would be part of an RA an
another would not. Logically, it's really a collection level attribute.
Thus since it will always be needed on every update request adding a watcher as
you suggest and caching locally would merely duplicate what's already cached at
the ZkStateReader level, and delay the uptake of new information by the time it
took the notification thread to make the adjustment.
I guess it's true that if one is using a non-java client or otherwise not using
CloudSolrClient, this would lead to caching collection properties information
on nodes not containing that collection but that would be necessary anyway to
ensure proper handling of RoutedAliases.
I am heartened by your characterization of the configuration stored as
"simple", but of course this is not enforced. Do you think there is risk that
something heavy is being stored in Collection properties and caching props for
other collections would become significant? If this looks like a problem maybe
we should add a system property or other configuration (cluster property?) to
turn off the entire RoutedAlias feature set (which would just be an addition to
the org.apache.solr.update.processor.RoutedAliasUpdateProcessor#wrap method and
therefore fairly simple) Then the only case that would be hard to handle is
heavy values in collection properties and a desire to use RoutedAliases.
(as a side note this is yet another case where the lack of
https://issues.apache.org/jira/browse/ZOOKEEPER-1416 forces us to watch entire
blobs of json when we only care about one atribute... )
> 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
