curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ioannis Canellos (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-14) Memory leak in Curator watches
Date Sun, 16 Jun 2013 14:49:21 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684679#comment-13684679
] 

Ioannis Canellos commented on CURATOR-14:
-----------------------------------------

Apparently there is something I am missing here :-D

So the main problem is that there is no way to clear a Watcher that has been assigned to ZooKeeper.

Eventually this can lead to a memory leak since its not possible to garbage collect Watcher
instances.
In order to workaround this problem we should limit the amount of Watchers we create and reuse
Watcher instances when its possible.

Currently curator is using Guava's cache that uses "weak values" so that values can be garbage
collected (once they are weakly reachable). This is done transparently whenever we call usingWatcher
via Watching.

There are a couple of things that I don't understand here:

i) If using "guava's cache" was enough, then what is to be implemented for this issue? The
cache is already in place and is already being used in a transparent way.
ii) Does the garbage collector ever manage to collect values of the cache, given that they
are not cleared in ZooKeeper? From some tests I run using a modified version of the attached
MemoryTest I don't see any value getting garbage collected.



                
> Memory leak in Curator watches
> ------------------------------
>
>                 Key: CURATOR-14
>                 URL: https://issues.apache.org/jira/browse/CURATOR-14
>             Project: Apache Curator
>          Issue Type: New Feature
>          Components: Recipes
>    Affects Versions: 2.0.0-incubating
>            Reporter: Brandon Beck
>            Priority: Minor
>         Attachments: CURATOR-14-draft-2.patch, CURATOR-14-draft-3.patch, CURATOR-14.patch,
MemoryTest.java
>
>
> The JVM runs out of memory if you repetitively create a PathChildrenCache, start it then
immediately stop it.  It appears that the memory is taken up by a watch that isn't ever cleaned
up.  Curator attempts to do some pooling of watches, but doesn't seem to use the path in the
pooling.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message