You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@helix.apache.org by "Zhen Zhang (JIRA)" <ji...@apache.org> on 2014/10/14 01:50:35 UTC

[jira] [Created] (HELIX-527) Mitigate zookeeper watch leak

Zhen Zhang created HELIX-527:
--------------------------------

             Summary: 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)