[ 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)