axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trenton D. Adams" <>
Subject Re: Memory leak in Tomcat
Date Thu, 02 Feb 2012 17:18:43 GMT
I have seen instances where a library in tomcat itself is the same 
library I'm using, and it is that library that is holding on to a 
reference to the class loader of the webapp.  Normally, once the 
classloader is discarded for garbage collection, every reference it 
holds will also end up being garbage collected.  But, if a library 
instance from tomcat itself is still holding on to the class loader, 
then that can't happen.

I can't remember why *exactly* this happens, because normally each 
context gets it's own class loader, and therefore a new instance of any 
library in that webapp.  But, I believe there was some special stuff 
going on, that caused the library instance in tomcat to get the reference.

If I recall correctly, in my case it was commons logging.  I just 
decided to live with it, pump up my permgen, and restart tomcat when 
needed. :(

Anyhow, I vaguely recall using jvisualvm to diagnose the problem, which 
led me to doing an appropriate google search, and finding that others 
had the same problem with the same library.  But, that was a bit of work. :P

Le 12-02-01 09:25 AM, James Annesley a écrit :
> Hi,
> I have an XML beans based AXIS 2 1.6.0 stub. After using the client's UI for
> a short period of time - say a few minutes - having un-deployed the web app
> I get about 50 or so messages as follows:
> 01-Feb-2012 16:21:48 org.apache.catalina.loader.WebappClassLoader
> checkThreadLocalMapForLeaks
> SEVERE: The web application [/xxxx] created a ThreadLocal with key of type
> [org.apache.xmlbeans.XmlBeans$1] (value
> [org.apache.xmlbeans.XmlBeans$1@561915df ]) and a value of type
> [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@1a4d1557])
> but failed to remove it when the web application was stopped. Threads are
> going to be renewed over time to try and avoid a probable memory leak.
> Can anyone shed any light on this?
> Best
> James
> Infoshare Ltd
> Millennium House
> 21 Eden Street
> Kingston upon Thames
> Surrey
> KT1 1BL
> United Kingdom
> Phone: 		+ 44 (0) 20 8541 0111
> Support:	+ 44 (0) 20 8481 4760
> Web:
> E-mail:
> Infoshare Ltd is registered in England and Wales.
> Registered Office as above.
> Registered Number 2877612
> VAT Number GB 678 1443 10
> The content of this e-mail (and any attachment to it) is confidential.
> Any views or opinions do not represent the views or opinions
> of Infoshare Ltd.
> If you have received this e-mail in error please notify the sender
> and delete it. You may not use, copy or disclose the information
> in any way.
> Infoshare Ltd monitors incoming and outgoing e-mails.
> Please consider the environment. Do you really need to print
> this email?

Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195

    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message