lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13491) SolrZkClient can register the same watch twice.
Date Sat, 25 May 2019 16:39:00 GMT

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

Erick Erickson commented on SOLR-13491:
---------------------------------------

We're routinely seeing many hundreds of replicas, so I should think anything we can do to
reduce the load on ZK would be A Good Thing.

[~gus_heck] Do you have any inkling of whether moving to ZK 3.5.5 would affect either the
problem or the solution? I'm fairly close to being able to commit SOLR-8346.

> SolrZkClient can register the same watch twice.
> -----------------------------------------------
>
>                 Key: SOLR-13491
>                 URL: https://issues.apache.org/jira/browse/SOLR-13491
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>    Affects Versions: 8.0
>            Reporter: Gus Heck
>            Priority: Major
>
> While working on SOLR-13420 and related tickets I noticed that we presently use the wrapWatch()
method to wrap all zookeeper watches. This allows the watch to be processed asynchronously
by an executor which is good, but it subtly changes the way zookeeper behaves. Normally zookeeper
keeps a Map<String,Set<Watch>> that ensures that if the same watch is registered
twice it's only notified once. However, our wrapper breaks this because now, if the same watch
is added twice each one gets it's own wrapper with default Object.equals() and thus the two
wrapped versions of the Watch aren not .equals() and may co-exist in the Set<Watch>
> I do not know of any current cases for which this would cause a problem, but changes
I am contemplating for SOLR-13375 are likely to hit this case and at a minimum create wasted
re-notifications of the same event and excess watch load in Zk.
> Moving the anonymous class wrapping to an explicit inner class and writing hashcode/equals
carefully to act as a pass through such that any to wrappers with the same watch object are
.equals() should fix this.



--
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


Mime
View raw message