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 Fri, 18 Dec 2015 01:06:36 GMT
Looking at the IBM support web site it seems Websphere AS 7 standard support would have ended
in 2013 and enhanced support will end in 2016, AS 8.0 standard support will end next July
with enhanced support continuing until 2019.  Only Websphere 8.5 supports Java 7.

Weblogic Server 10 had a premier end of support date of 2014 and an extended end of support
date of 2017. I didn’t look to see what Java versions it supported. From what I can tell
Weblogic server 11g supports Java 7. In general, Oracle seems to say they support any “Certified
Java Version”.

Ralph

> On Dec 17, 2015, at 12:30 PM, 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