logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
Date Thu, 17 Dec 2015 21:31:30 GMT
Yes, and some of the patches and fixes from 2.4+ can be back ported to 2.3.1, etc if there
is interest and anyone is willing to help out. 

Ralph

> On Dec 17, 2015, at 1:16 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> Hello,
> 
> Log4j 1 has reached EOL. For Java 6 support you can use 2.3.
> 
> Gary
> On Dec 17, 2015 11:30 AM, "Dave Glasser" <dglasser@pobox.com> wrote:
> 
>> 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.Guna@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>> 
>> 
>> 



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


Mime
View raw message