[
https://issues.apache.org/jira/browse/CURATOR-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611555#comment-16611555
]
Tim Harper commented on CURATOR-478:
------------------------------------
Hmm, seems like we could also run into an issue with BackgroundCallback.
What would you think if we used an atomicInteger and incremented it each time,
then cancelled if the atomic int value didn't match the value at the time we
registered the callback?
> 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)
