Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of josh.elser@gmail.com designates
 209.85.216.42 as permitted sender)
Message-ID: <5177E833.9040304@gmail.com>
Date: Wed, 24 Apr 2013 10:12:03 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: user@accumulo.apache.org
Subject: Re: PermGen leak in JBoss
References: <1F768E0365ED884CA8D9A3A315D04401084B1A92@shark6.netcentric.local>
In-Reply-To: 
 <1F768E0365ED884CA8D9A3A315D04401084B1A92@shark6.netcentric.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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
>
>