To any Log4j devs on the list, if Veit has found a bug in 1.2.17, please,
please, fix it and release 1.2.18. I cannot use 2.5 because my code has to run
under Java 1.6. I suspect that is the case with a lot of developers who deploy
on WebSphere or WebLogic.
From: Veit Guna <veit.g...@gmx.de>
To: log4j-user@logging.apache.org
Sent: Thursday, December 17, 2015 12:36 PM
Subject: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
Hi.
We're developing a Jersey 2(.22.1) REST service with JDK8, log4j 1.2.16
and SLF4J 1.7.7 using Tomcat 8.0.23.
Recently I stumbled across the problem mentioned here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=50486
Where Tomcat complains about left behind ThreadLocalMaps.
I updated to 1.2.17 which claims to fix the mentioned problem.
On first sight, it did. Starting the server and immediately stopping it
showed no warning anymore - before it did. Yay!
But then I drove some loadtests against our REST service and after
stopping it the same message appeared again :(.
I double checked that our MDC put/remove is performed within a
try/finally within a http filter. I also logged, what values
were put and removed from the MDC - everyting as expected.
I also made sure, that the key was really removed after
MDC.remove() by getting the key from the MDC again: null.
Tomcat complained about a specific key/value in the ThreadLocalMap.
I checked, that this key/value was logged before - and it was
logged as "removed". So somehow it wasn't _really_ removed.
I digged deeper into the rabbit hole and found this peace of code:
--cut here--
final public class ThreadLocalMap extends InheritableThreadLocal {
public
final
Object childValue(Object parentValue) {
Hashtable ht = (Hashtable) parentValue;
if(ht != null) {
return ht.clone();
} else {
return null;
}
}
}
--cut here--
At this point, the hashtable containing the key/values is cloned
when a child thread is spawned. That would explain, why I see that
the complained key/value still exists, although I removed it from the
MDC. It still exists in the cloned instance on the spawned child thread
I guess!
I verified it by debugging within eclipse and set a breakpoint there,
simply returning null instead of ht.clone(). And voila: no complaining
anymore when shutting down.
Since I'm not too deep into log4j, could someone of the devs please
shed some light on this, please?
I'm wondering, who will remove the ThreadLocalMap on the spawned child
threads? Since MDC.remove() will do this only on my parent thread
manually kicked by the filter.
Or, maybe I'm completely wrong with this :).
Thanks
Veit
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
