On Wed, Apr 24, 2013 at 10:12 AM, Josh Elser <[email protected]> wrote:
> Giving a quick glance at that code again, the only thing I see that would > be active is the ZooKeeperInstance (ZooCache) which will try to stay > connected/updated to ZooKeeper. However, that should also disconnect/expire > itself. > > What's the time frame in which you're redeploying your webapp (within a > few seconds, minutes)? Also, threadname/stacktrace for said 5 threads would > be helpful/enlightening. Yeah those stack traces would be nice if you have them. I suspect one culprit may come from o.a.accumulo.core.client.impl.ThriftTransportPool, but I am curious about the stack traces. I am going to try firing up a client and doing what you did in 1.4 and looking at the stacks. > > > On 4/24/13 9:48 AM, Michael Giordano wrote: > >> Under version 1.3.7 we are using the following code to initialize a >> cloudbase connection during initialization of our web app: >> >> ZooKeeperInstance instance = new >> ZooKeeperInstance(**instanceName, zooKeepers); >> connector = instance.getConnector(userId, >> password.getBytes()); >> >> The problem is that under the hood, this call creates several (5) threads >> that are not cleaned up when the app is undeployed in JBoss. This is >> occurring without performing any scans or interacting with cloudbase in any >> other way. After relatively few redeploys of the app, the PermGen Space is >> OOM. >> >> I can't find any reference in the cloudbase API akin to a close() method >> for the Connector object. This is a classloader leak effecting any webapp >> that is accessing cloudbase directly. The result of this leak is not simply >> orphaned threads, but thousands of classes not gc'd because the classloader >> itself can't be gc'd. This is what is filling up PermGen. >> >> Has anyone discovered this particular issue? Has anyone discovered a >> solution? >> >> Thanks, >> Mike G. >> >> NetCentric Technology, Inc. >> 3349 Route 138, Building A >> Wall, NJ 07719 >> Phone: 732-544-0888 >> >> >> >
