We are using zookeeper 3.5.1. It seems from your message that we are not vulnerable to this issue?
On Wed, Aug 31, 2016 at 10:44 AM, Lei Xia (JIRA) <[email protected]> wrote: > > [ > 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)
