[
https://issues.apache.org/jira/browse/CURATOR-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Harper updated CURATOR-478:
-------------------------------
Description:
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.
was:
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.
> 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)
