[
https://issues.apache.org/jira/browse/CURATOR-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611571#comment-16611571
]
Tim Harper commented on CURATOR-478:
------------------------------------
I'm honestly not sure how I would add a unit test for this. It would be really
hard to reliably create the conditions leading to this issue.
> 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)
