curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Tschetter (JIRA)" <>
Subject [jira] [Commented] (CURATOR-14) Memory leak in Curator watches
Date Wed, 19 Jun 2013 18:53:20 GMT


Eric Tschetter commented on CURATOR-14:

I haven't been too privy to the full context of this, so forgive me if this was discussed
somewhere and shot down already.

But, instead of pooling watches, I believe that if there was one large global watcher that
could essentially be re-used for everything, then that would significantly reduce the memory
footprint required by the ZooKeeper object to store watches.  That is, its internal data structures
would just be a bunch of references to the same actual object, so you just pay the cost of
the extra references.  Given that it stores things as a Set<> on a path, it would only
store it once for each path as well.  This global watcher could have Curator-specific registration
mechanisms that allow it to have watchers registered and unregistered so that you can re-create
the current behavior and get the semantics that we want.

Does that make sense?
> 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