Ok, great! Patrick
On Mon, Feb 14, 2011 at 1:23 PM, Johannes Zillmann <[email protected]> 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 >> <[email protected]> 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 > >
