[
https://issues.apache.org/jira/browse/HELIX-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452861#comment-15452861
]
Lei Xia commented on HELIX-527:
-------------------------------
We may need to reevaluate this issue and figure out the solution. Assigned to
me, and I will spend some time on this issue.
> Mitigate zookeeper watch leak
> -----------------------------
>
> Key: HELIX-527
> URL: https://issues.apache.org/jira/browse/HELIX-527
> Project: Apache Helix
> Issue Type: Bug
> Reporter: Zhen Zhang
>
> On investigating zookeeper watch leakage problem, it turns out to be a
> zookeeper issue:
> https://issues.apache.org/jira/browse/ZOOKEEPER-442
> For zookeeper before 3.5.0, we can't remove watches that are no longer of
> interests. The only way to remove a watch is to trigger it; that is, if it is
> a DataWatch, we need to trigger a data change on the watching path, or if it
> is a ChildWatch, we need to trigger a child change on the watching path.
> Unfortunately, if we are watching a path that has been deleted, unless we
> re-create the path, there is no way we can remove the watch.
> Here are some of the most common scenarios where we will have dead zookeeper
> watches on zookeeper server side even though we unregister all the listeners
> on the zookeeper client side:
> - When we drop a resource group from a cluster, we may have dead watches on
> ideal-state, participant current-state, and external-view
> - When we remove an instance from a cluster, we may have dead watches on
> current-state, participant-config, and participant messages
> - When we use property store with caches enabled by zookeeper watches, we may
> have dead watches on all removed paths
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
