Thanks for your very helpful answers.
I shall gradually cut out reflectionToString: unfortunately I've used it
quite a lot, because it was useful!
Thanks again,
Malcolm Warren
Cyrille Le Clerc ha scritto:
Hello,
Your threadLocal variable is created by the reflectionToString feature
of Jakarta Commons Lang ToStringBuilder (1).
This thread local variable seems to be used to prevent infinite
recursion when ToStringBuilder traverse the objects.
I didn't see yet a way (servlet filter, etc) to cleanup this ThreadLocal.
Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr
(1)
http://fisheye6.atlassian.com/browse/commons/proper/lang/trunk/src/java/org/apache/commons/lang/builder/ToStringStyle.java?r=594386#l136
On Tue, Feb 2, 2010 at 2:44 PM, Mark Thomas <ma...@apache.org> wrote:
On 02/02/2010 13:31, Malcolm Warren wrote:
SEVERE: A web application created a ThreadLocal with key of type
[org.apache.commons.lang.builder.ToStringStyle$1] (value
[org.apache.commons.lang.builder.tostringstyl...@66a37d72]) and a value
of type [java.util.HashSet] (value [[]]) but failed to remove it when
the web application was stopped. To prevent a memory leak, the
ThreadLocal has been forcibly removed.
I get this message with every hot redeploy, which is a little worrying.
Anybody know what it's about?
The message says it all. Something created a ThreadLocal but didn't
clean it up. Tomcat cleaned it up to prevent a memory leak.
This started with the latest Tomcat 6 version: 6.0.24.
I'm pleased with this new version because it also pointed out politely
that I hadn't closed a thread I'd opened.
This is all part of the new memory leak protection added for 6.0.24. It
is good to hear that people are finding it useful.
I've fixed my Thread but I still get the message shown at the beginning
of this email.
I don't use ThreadLocal in my code at all, so it's Tomcat who's creating
this ThreadLocal for some reason, but since it's not mine it's something
I can't do much about, presumably.
It isn't Tomcat's (Tomcat doesn't ship with commons-lang) so I am pretty
sure it is yours. Chances are it isn't something you are doing directly
but maybe something a library you are using is doing?
If a library is adding a ThreadLocal to a request processing thread it
*must* remove it before the request completes to avoid a potential
memory leak. If it doesn't, I would argue that is a bug in the library.
At a stretch, if the library provides a mechanism to clean these up on
web app shutdown that is just about OK but that could would need to be
carefully coded.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
