Oh, yes, here's the docs on that. As you can see, you can write a
ServletContextListener to unregister the class loader from the logger
library.
http://wiki.apache.org/commons/Logging/UndeployMemoryLeak
So, if you can find that there is something similar in the library
you're having a problem with, you should be able to write a small
ServletContextListener to unregister it as well, assuming the problem is
similar.
Anyhow, like I said, I just live with it, because typically this is only
a problem in my workstations, since I redeploy so often.
Le 12-02-02 10:18 AM, Trenton D. Adams a écrit :
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: www.infoshare-is.com
E-mail: i...@infoshare-is.com
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
:wq!
--
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: java-user-unsubscr...@axis.apache.org
For additional commands, e-mail: java-user-h...@axis.apache.org
