[jira] [Commented] (CURATOR-478) LeaderLatch accumulates additional watcher handlers

["Jordan Zimmerman (JIRA)" <ji...@apache.org>]

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

Jordan Zimmerman commented on CURATOR-478:
------------------------------------------

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)