One is for the dynamic reloading of the log4j configuration, IIRC. -Eric
On Wed, Apr 24, 2013 at 11:44 AM, Keith Turner <[email protected]> wrote: > > > > On Wed, Apr 24, 2013 at 11:21 AM, Heath Abelson < > [email protected]> wrote: > >> Hi, I am a colleague of Michael's, I can provide more info >> >> The following are the 5 threads that are not being cleaned up on an >> undeploy. It's hard to get more stack info than this. >> >> Daemon Thread [FileWatchdog] (Running) >> Daemon Thread [MSC service thread 1-5-SendThread(cbdbtestbox:2181)] >> (Running) >> Daemon Thread [MSC service thread 1-5-EventThread] (Running) >> Daemon Thread [Thrift Connection Pool Checker] (Running) >> Daemon Thread [FileWatchdog] (Running) >> >> Using Plumbr, the report states that the SendThread and EventThread above >> both contain an instance of org.apache.zookeeper.ClientCnxn >> > > So two zookeeper threads. An Accumulo thread (Thrift Connection Pool > Checker). What are the FileWatchdog threads? Those could be related to > accumulo-start or hdfs. > > >> >> -Heath >> >> -----Original Message----- >> From: Michael Giordano >> Sent: Wednesday, April 24, 2013 9:48 AM >> To: [email protected] >> Subject: PermGen leak in JBoss >> >> 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 >> >> >> >
