[
https://issues.apache.org/jira/browse/SOLR-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851917#comment-16851917
]
ASF subversion and git services commented on SOLR-13491:
--------------------------------------------------------
Commit 6ede32a0796eead46c214104d92c083aabb18f2d in lucene-solr's branch
refs/heads/master from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6ede32a ]
SOLR-13491 - Touch-up test. Beasting failed 1/50 (5) Now passes 500/500 (20).
> 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
> Attachments: SOLR-13491.patch, SOLR-13491.patch
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
