curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Tschetter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-14) Memory leak in Curator watches
Date Sat, 13 Jul 2013 02:31:50 GMT

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

Eric Tschetter commented on CURATOR-14:
---------------------------------------

I finally had a chance to look at code and not just talk in high level abstractiness, but
I don't see why we cannot have an unregister method now (and I wonder if, without that, we
aren't just re-implementing the watcher mechanism that ZK already has).

It seems like we should be able to adjust DispatchingWatcher to have an unregister() method
on it.  We can then put methods for registering and returning the watcher directly on the
CuratorFramework along with methods to unregister the watcher.  Simple object equality should
be sufficient for removing the watcher from the Set in DispatchingWatcher.  The big concern
here is race conditions around a watch getting fired and it being unregistered concurrently.
 I think this is a fine concern to bubble up to the users, they have to write their Watchers/close
methods with the understanding that even if they are currently unregistering the watcher,
it could still get called.

Then all of the recipes that end up calling the builders with a "usingWatcher" will have the
ability to remove their watchers from the base CuratorFramework when their respective close()
methods are called.

Hopefully that makes sense?
                
> 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-dispatchingwatcher.patch, 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