[
https://issues.apache.org/jira/browse/CURATOR-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607439#comment-16607439
]
Jordan Zimmerman edited comment on CURATOR-478 at 9/7/18 5:58 PM:
------------------------------------------------------------------
I took a quick look and you're probably correct. A simple solution is to
allocate the watcher as a field of the class. ZooKeeper guarantees that if you
use the same watcher for the same path is only registered once.
was (Author: randgalt):
I took a quick look and you're probably correct. A simple solution is to
allocate the watcher as a field of the class. ZooKeeper guarantees that if you
the same watcher for the same path is only registered once.
> LeaderLatch accumulates additional watcher handlers
> ---------------------------------------------------
>
> Key: CURATOR-478
> URL: https://issues.apache.org/jira/browse/CURATOR-478
> Project: Apache Curator
> Issue Type: Bug
> Reporter: Tim Harper
> Assignee: Jordan Zimmerman
> Priority: Trivial
>
> In the event of a connection reconnect, LeaderLatch calls reset():
> https://github.com/apache/curator/blob/9a03ea93937af047e8ad13c2e3e3559520abfb0a/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderLatch.java#L613
> Ultimately, this results in another call to getChildren(), which calls
> checkLeadership(), which registers another getData watch for the ephemeral
> leader record preceding our new leader record. However, the watch in place
> from before reset() is in place, and will trigger yet _another_ watch in the
> event that the record it is watching gets deleted.
> As such, the number of pending watchers (at least client side) will continue
> to increase each time the connection fails over.
> Marked as trivial because I think it's unlikely these accumulate to the point
> that it's an issue, but it seems like it should at least be called out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
