Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4992CA16.4000709@apache.org>
Date: Wed, 11 Feb 2009 12:52:38 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Weblogic library and Tomcat
References: <1234351627.15112.58.camel@localhost.localdomain>
In-Reply-To: <1234351627.15112.58.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Pieter Temmerman wrote:

> First of all, I'm not sure how I can figure out where the references to
> the prior instances are being maintained, and secondly, I don't know how
> to clean them up (both are closely related if you ask me :-) )

You are on the right track with a profiler. I use (and highly recommend)
YourKit. I get a free copy as an Apache developer for investigating Tomcat
related issues but it is reasonably priced and I have bought several copies for
different projects over the years. It usually returns the investment on the
first issue I fix.

As to the why - image a scenario such as this.

Tomcat starts
Tomcat (for some reason) loads a JDBC driver
The JDBC driver is registered with the driver manager
Note: Tomcat has to load the DriverManager to do this
Your webapp starts
Your web app loads a JDBC driver
Your web app registered the JDBC driver with the driver manager
Your web app stops
You have a huge memory leak.

Why?
Remembering that every class keeps a reference to the classloader that loaded it:
DriverManager was loaded by Tomcat
DriverManager has a reference to your JDBC driver
Your JDBC driver has a reference to the web application classloader
The web application class loader retains references to every class it has loaded

Hence none of your classes are unloaded and Tomcat has an instance of your web
application it can't garbage collect -> memory leak.

Repeat this a few times and you'll get an OOM.

As well as JDBC drivers, logging frameworks are frequent culprits for causing this.

> My first thought was to take thread dumps, but there aren't showing up
> any previous instances of the webapp.
> 
> I don't have any experience with profilers, but I can try to use
> VisualVM (which has a profiler-like tab) to take a look at all the
> objects being instantiated. 
> Say I find any references to Weblogic, how should I go about having them
> removed automatically each time the application is being redeployed?

You need to find which objects are holding on to a reference to the the weblogic
class and make sure it gets cleared when the app restarts. A context listener
might be useful here.

In the example above, you would need to remove the reference to your JDBC driver
from the DriverManager.

Profilers should provide utilities to trace references to instances of classes.

HTH,

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org