curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ioannis Canellos (JIRA)" <>
Subject [jira] [Commented] (CURATOR-14) Memory leak in Curator watches
Date Tue, 04 Jun 2013 13:31:20 GMT


Ioannis Canellos commented on CURATOR-14:

I had 2 kind of issues on the LockInternals:
i) I was unsure on when I should remove the watcher from the global map.
ii) I was unsure if its possibly that a watcher for the same path can be reused.

For (i) I thought that the most fitting place would be to remove the watcher, when it fired
(and maybe when we release the lock?).
For (ii) I used the internal map. I am totally unsure about that.

So please share your thoughts/ideas about it.

Regarding the WatcherKey, do u see it as a way of wrapping Watcher/CuratorWatcher objects
or you think that the recipes should directly use anonymous inner implementations of the WatcherKey?

> 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