Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@logging.apache.org>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
From: Ralph Goers <ralph.goers@dslextreme.com>
In-Reply-To: <975545136.351334.1450380617274.JavaMail.yahoo@mail.yahoo.com>
Date: Thu, 17 Dec 2015 18:06:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4AE7932-D80F-459B-96AA-3BA169400857@dslextreme.com>
References: 
 <trinity-0af4bcd6-240b-442a-9473-98b2cf135fc6-1450373808191@3capp-gmx-bs55>
 <975545136.351334.1450380617274.JavaMail.yahoo@mail.yahoo.com>
To: Log4J Users List <log4j-user@logging.apache.org>,
 Dave Glasser <dglasser@pobox.com>

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=E2=80=99t look to see what =
Java versions it supported. =46rom what I can tell Weblogic server 11g =
supports Java 7. In general, Oracle seems to say they support any =
=E2=80=9CCertified Java Version=E2=80=9D.

Ralph

> On Dec 17, 2015, at 12:30 PM, Dave Glasser <dglasser@pobox.com> wrote:
>=20
> 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.=20
>=20
>=20
>=20
>      From: Veit Guna <Veit.Guna@gmx.de>
> To: log4j-user@logging.apache.org=20
> Sent: Thursday, December 17, 2015 12:36 PM
> Subject: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
>=20
> Hi.
>=20
> 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.
>=20
> Recently I stumbled across the problem mentioned here:
>=20
> https://bz.apache.org/bugzilla/show_bug.cgi?id=3D50486
>=20
> Where Tomcat complains about left behind ThreadLocalMaps.
>=20
> 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!
>=20
> But then I drove some loadtests against our REST service and after
> stopping it the same message appeared again :(.
>=20
> 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.
>=20
> 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.
>=20
> I digged deeper into the rabbit hole and found this peace of code:
>=20
> --cut here--
> final public class ThreadLocalMap extends InheritableThreadLocal {
>=20
>   public
>   final
>   Object childValue(Object parentValue) {
>     Hashtable ht =3D (Hashtable) parentValue;
>     if(ht !=3D null) {
>       return ht.clone();
>     } else {
>       return null;
>     }
>   }
> }
> --cut here--
>=20
> 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!
>=20
> 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.
>=20
> Since I'm not too deep into log4j, could someone of the devs please
> shed some light on this, please?
>=20
> 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.
>=20
> Or, maybe I'm completely wrong with this :).
>=20
> Thanks
> Veit
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> =20
> =20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>=20
>=20


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