[
https://issues.apache.org/jira/browse/CURATOR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688309#comment-13688309
]
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: 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
