Hi I think it maybe not a problem. In the test code,the so many serviceprovders have the reference to the first servicediscovery which is not released a,so they can not gc .
At 2014-04-29 18:55:55,"Joe Littlejohn" <[email protected]> wrote: Hi, I've observed a memory leak in our production system using Curator service discovery. I can replicate the problem with 2.4.1 and 2.4.2, though I haven't tested any older versions. This test shows the problem: https://www.refheap.com/82891 (Hopefully this test is enough to demonstrate the problem. I haven't used the TestingServer so you'll need a zk instance with a registered service.) If you run it 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. I realise it's possible to retain ServiceProvider instances, but this appears to be a leak that shouldn't occur if the provider is correctly closed each time. Can anyone comment on whether this is indeed a problem? Am I missing something? Cheers
