curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <>
Subject [jira] [Commented] (CURATOR-14) Memory leak in Curator watches
Date Mon, 03 Jun 2013 21:28:20 GMT


Jordan Zimmerman commented on CURATOR-14:


* WatcherMap should extend Closeable
* JavaDoc @return on WatcherMap is empty
* Why is WatcherMap.get() parameterized? Shouldn't it just return Watcher?
* NamespaceWatcher.warp() is misspelled
* DistributedDoubleBarrier.acutalWatcher is misspelled
* I think that WatcherMap should introduce a new Interface other than re-using Watcher. It's
a bit confusing to use a ZooKeeper Watcher as a key. Maybe a new interface called WatcherKey
or something. I realize that this is how I had it but now that it's getting distributed throughout
the code base I can see that it's confusing. This will also prevent a bad watcher from getting
passed to Curator/ZooKeeper.
* Why is LockInternals.internalWatcherMap needed?

> Memory leak in Curator watches
> ------------------------------
>                 Key: CURATOR-14
>                 URL:
>             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,
> 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

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:

View raw message