Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@logging.apache.org>
MIME-Version: 1.0
In-Reply-To: <504377321.459652.1450397049960.JavaMail.yahoo@mail.yahoo.com>
References: 
 <CACZkXPzshJU5iTjkfQthebAbG8TKYvYiyb8hjWrBP=pHVUNfAw@mail.gmail.com>
	<504377321.459652.1450397049960.JavaMail.yahoo@mail.yahoo.com>
Date: Thu, 17 Dec 2015 16:08:36 -0800
Message-ID: 
 <CACZkXPwX_r0nYDNuz7+yL2jAWdbOZ99LWouO=hGu6L88rVc6QQ@mail.gmail.com>
Subject: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
From: Gary Gregory <garydgregory@gmail.com>
To: Log4J Users List <log4j-user@logging.apache.org>,
 Dave Glasser <dglasser@pobox.com>
Content-Type: multipart/alternative; boundary=001a1141072cd057b2052720f07d

--001a1141072cd057b2052720f07d
Content-Type: text/plain; charset=UTF-8

FYI: I'm pretty sure we will not see a 2.3 branch maintained at parity with
master, I do not see anyone here so far that has expressed interest in such
an effort. If you'd like to help out, you are more than welcome to do so.
There is a possibility for a 2.3.x branch to backport selected fixes
though, again, help wanted. Aside from that my efforts focus on master.

Gary

On Thu, Dec 17, 2015 at 4:04 PM, Dave Glasser <dglasser@pobox.com> wrote:

> The bugs don't matter, because, as I mentioned, the main blocker for me in
> the 2.x branch is that I need to ability to programmatically configure
> log4j, and change the configuration at runtime. It might get there, in fact
> 2.5 might be there, but Java 1.7 is a no-go for me.
> If you guys are going to actively maintain a Java 1.6-compatible branch
> that's forked from log4j 2.3, my suggestion would be to keep all the bug
> fixes and functionality aligned with the main branch, except for the lamda
> stuff that doesn't work under Java 1.6. But that's just a suggestion. I'll
> be sticking with the 1.2.x branch for the foreseeable future.
>
>
>
>       From: Gary Gregory <garydgregory@gmail.com>
>  To: Log4J Users List <log4j-user@logging.apache.org>; Dave Glasser <
> dglasser@pobox.com>
>  Sent: Thursday, December 17, 2015 6:32 PM
>  Subject: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap
>
> Can you list which bugs in JIRA you'd like to have in what could possibly
> be a 2.3.1 release?
>
> Gary
>
> On Thu, Dec 17, 2015 at 2:57 PM, Dave Glasser <dglasser@pobox.com> wrote:
>
> > 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 <garydgregory@gmail.com>
> >  To: Dave Glasser <dglasser@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" <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
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
> --
> 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
>
>
>


-- 
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

--001a1141072cd057b2052720f07d--