You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2019/04/23 16:30:00 UTC

[jira] [Commented] (SOLR-13418) ZkStateReader.PropsWatcher synchronizes on a string value & doesn't track zk version

    [ https://issues.apache.org/jira/browse/SOLR-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824303#comment-16824303 ] 

ASF subversion and git services commented on SOLR-13418:
--------------------------------------------------------

Commit 80d3ac8709c6d93c4e4634dc7c10ef667a029cb1 in lucene-solr's branch refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=80d3ac8 ]

SOLR-13418 - safer synchronization and zk version checking for collection properties


> 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
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org