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 Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
Date Thu, 17 Dec 2015 21:29:25 GMT
Hi Gary.

I can give it a try tomorrow. Has the log4j.xml format been changed? Or does the bridge handle
that too?


Am 17. Dezember 2015 19:16:24 MEZ, schrieb Gary Gregory <garydgregory@gmail.com>:
>Is there any chance you can update your app to Log4j 2.5 using our 1.2
>bridge?
>
>Gary
>
>On Thu, Dec 17, 2015 at 9:36 AM, Veit Guna <Veit.Guna@gmx.de> wrote:
>
>> 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
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@apache.org
>Java Persistence with Hibernate, Second Edition
><http://www.manning.com/bauer3/>
>JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>Spring Batch in Action <http://www.manning.com/templier/>
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory

-- 
Von meinem Telefon gesendet.
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message