You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Johannes Zillmann <jz...@googlemail.com> on 2011/02/14 09:39:27 UTC

garbage collection of ZooKeeper class

Dear folks,

i'm currently debugging a possible-memory leak in an application which uses zookeeper.
I found ZooKeeper$ZkWatchManager.existWatches growing large - probably a usage problem.

However i'm running a small test app in loop a session expiration happens from time to time. 
On an expired event the app closes the current ZooKeeper instance on and creates a new instance of it.
What i found out through debugging is that the number of ZooKeeper instances in the system is constantly growing, with most instances in state CLOSED. 
Forcing GC doesn't change anything here. Looking at the references it i seems like a closed ZooKeeper instance is only referenced by a ClientCnxn, and this ClientCnxn is referenced only bye a ZooKeeper + Send- and Event-thread.
So i suspect this reference cycle prevents the garbage collection...

Johannes

Re: garbage collection of ZooKeeper class

Posted by Patrick Hunt <ph...@apache.org>.
Ok, great!

Patrick

On Mon, Feb 14, 2011 at 1:23 PM, Johannes Zillmann
<jz...@googlemail.com> wrote:
> Hi Patrick,
>
> On Feb 14, 2011, at 6:36 PM, Patrick Hunt wrote:
>
>> What version are you using? Perhaps you are hitting this one?
>> https://issues.apache.org/jira/browse/ZOOKEEPER-795
>
> Looks like this is the case, at least i couldn't reproduce the problem after upgrading from 3.3.1 to 3.3.2.
> Thanks !
> Johannes
>
>
>>
>> You might try doing a stack dump (jstack) on the client to determine
>> if leaking threads might be the cause.
>>
>> Patrick
>>
>> On Mon, Feb 14, 2011 at 12:39 AM, Johannes Zillmann
>> <jz...@googlemail.com> wrote:
>>> Dear folks,
>>>
>>> i'm currently debugging a possible-memory leak in an application which uses zookeeper.
>>> I found ZooKeeper$ZkWatchManager.existWatches growing large - probably a usage problem.
>>>
>>> However i'm running a small test app in loop a session expiration happens from time to time.
>>> On an expired event the app closes the current ZooKeeper instance on and creates a new instance of it.
>>> What i found out through debugging is that the number of ZooKeeper instances in the system is constantly growing, with most instances in state CLOSED.
>>> Forcing GC doesn't change anything here. Looking at the references it i seems like a closed ZooKeeper instance is only referenced by a ClientCnxn, and this ClientCnxn is referenced only bye a ZooKeeper + Send- and Event-thread.
>>> So i suspect this reference cycle prevents the garbage collection...
>>>
>>> Johannes
>
>

Re: garbage collection of ZooKeeper class

Posted by Johannes Zillmann <jz...@googlemail.com>.
Hi Patrick,

On Feb 14, 2011, at 6:36 PM, Patrick Hunt wrote:

> What version are you using? Perhaps you are hitting this one?
> https://issues.apache.org/jira/browse/ZOOKEEPER-795

Looks like this is the case, at least i couldn't reproduce the problem after upgrading from 3.3.1 to 3.3.2.
Thanks !
Johannes


> 
> You might try doing a stack dump (jstack) on the client to determine
> if leaking threads might be the cause.
> 
> Patrick
> 
> On Mon, Feb 14, 2011 at 12:39 AM, Johannes Zillmann
> <jz...@googlemail.com> wrote:
>> Dear folks,
>> 
>> i'm currently debugging a possible-memory leak in an application which uses zookeeper.
>> I found ZooKeeper$ZkWatchManager.existWatches growing large - probably a usage problem.
>> 
>> However i'm running a small test app in loop a session expiration happens from time to time.
>> On an expired event the app closes the current ZooKeeper instance on and creates a new instance of it.
>> What i found out through debugging is that the number of ZooKeeper instances in the system is constantly growing, with most instances in state CLOSED.
>> Forcing GC doesn't change anything here. Looking at the references it i seems like a closed ZooKeeper instance is only referenced by a ClientCnxn, and this ClientCnxn is referenced only bye a ZooKeeper + Send- and Event-thread.
>> So i suspect this reference cycle prevents the garbage collection...
>> 
>> Johannes


Re: garbage collection of ZooKeeper class

Posted by Patrick Hunt <ph...@apache.org>.
What version are you using? Perhaps you are hitting this one?
https://issues.apache.org/jira/browse/ZOOKEEPER-795

You might try doing a stack dump (jstack) on the client to determine
if leaking threads might be the cause.

Patrick

On Mon, Feb 14, 2011 at 12:39 AM, Johannes Zillmann
<jz...@googlemail.com> wrote:
> Dear folks,
>
> i'm currently debugging a possible-memory leak in an application which uses zookeeper.
> I found ZooKeeper$ZkWatchManager.existWatches growing large - probably a usage problem.
>
> However i'm running a small test app in loop a session expiration happens from time to time.
> On an expired event the app closes the current ZooKeeper instance on and creates a new instance of it.
> What i found out through debugging is that the number of ZooKeeper instances in the system is constantly growing, with most instances in state CLOSED.
> Forcing GC doesn't change anything here. Looking at the references it i seems like a closed ZooKeeper instance is only referenced by a ClientCnxn, and this ClientCnxn is referenced only bye a ZooKeeper + Send- and Event-thread.
> So i suspect this reference cycle prevents the garbage collection...
>
> Johannes