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 <garydgreg...@gmail.com>
To: Log4J Users List <log4j-user@logging.apache.org>; Dave Glasser
<dglas...@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 <dglas...@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 <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
> >
> >
> >
>
>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@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
