[
https://issues.apache.org/jira/browse/CURATOR-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997592#comment-13997592
]
Jordan Zimmerman commented on CURATOR-105:
------------------------------------------
I've done some work on this, but there's more to do. The first problem is that
Curator's internal Watcher map is holding on to references. My current attempt
at a fix is to add CuratorFramework.clearWatcherReferences(). My testing shows
this clears most of the references. However, Guava's cache seems to be holding
onto additional references that I haven't figured out yet. Please have a look
at the branch CURATOR-105 and see if you can help on this.
> Memory leak when using PathChildrenCache
> ----------------------------------------
>
> Key: CURATOR-105
> URL: https://issues.apache.org/jira/browse/CURATOR-105
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework, Recipes
> Affects Versions: 2.4.1, 2.4.2
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
> Reporter: Joe Littlejohn
> Assignee: Jordan Zimmerman
> Labels: discovery
> Fix For: 2.5.0
>
> Attachments: ServiceCacheLeakTest.java
>
>
> I've observed a memory leak in our production system using Curator service
> discovery.
> If you run the attached test case and watch the process with jvisualvm you'll
> see that the heap grows and grows as the test is running. Taking a heap dump
> will reveal thousands of ServiceInstance and ServiceCacheImpl instances that
> are retained even though the provider is closed after each usage. The
> references appear to be traced back to the PathChildrenCache. This appears to
> be a leak that shouldn't occur if the provider is correctly closed each time.
> There is also a heap dump available here:
> https://dl.dropboxusercontent.com/u/10909453/heapdump-curator-leak.hprof.tar.gz
--
This message was sent by Atlassian JIRA
(v6.2#6252)
