[
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
