Unfortunately, in addition to the bugs in 2.3, there is missing functionality
that precluded me from using it. (The programmatic configuration features I
posted about in the last week or so.)
If there isn't currently any actively maintained branch that supports 1.6, I'll
have to work around it some other way.
From: Gary Gregory <garydgreg...@gmail.com>
To: Dave Glasser <dglas...@pobox.com>; Log4J Users List
<log4j-user@logging.apache.org>
Sent: Thursday, December 17, 2015 3:16 PM
Subject: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
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" <dglas...@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.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
>
>
>
