logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Veit Guna" <Veit.G...@gmx.de>
Subject still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
Date Thu, 17 Dec 2015 17:36:48 GMT

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:


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 {

  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 :).



To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message