Hi Ralph. Today I switched from log4j 1.2.17 to 2.5 while using SLF4J 1.7.7. Basically it works and the Memory Leak Warning doesn't seem to appear anymore under "normal" usage. BUT, when using: <Configuration monitorInterval="60"> ... There comes the little bugger again :): WARNING: The web application [mywebapp] appears to have started a thread named [Log4j2-Log4j2Scheduled-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745) I think you guys start a monitoring thread that polls the config, right :)? Although the documentation states, that it will be checked when the next log statement is performed - what, IMHO, is the right approach. In the JEE / Container world, starting threads by your own is not very welcome :). Maybe an option (useMonitoringThread) could help. For now I can live without the monitoring since the xml is packaged within a jar anyway. But that might change in the future. Regards, Veit
Gesendet: Freitag, 18. Dezember 2015 um 02:10 Uhr Von: "Ralph Goers" <ralph.go...@dslextreme.com> An: "Log4J Users List" <log4j-user@logging.apache.org> Betreff: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap Although the configuration format has changed, it shouldn’t be too difficult to figure out how to create a similar configuration in Log4j 2. If you have any problems at all please ask. We will be happy to help with that. Ralph > On Dec 17, 2015, at 2:29 PM, Veit Guna <veit.g...@gmx.de> wrote: > > Hi Gary. > > I can give it a try tomorrow. Has the log4j.xml format been changed? Or does > the bridge handle that too? > > > Am 17. Dezember 2015 19:16:24 MEZ, schrieb Gary Gregory > <garydgreg...@gmail.com>: >> Is there any chance you can update your app to Log4j 2.5 using our 1.2 >> bridge? >> >> Gary >> >> On Thu, Dec 17, 2015 at 9:36 AM, Veit Guna <veit.g...@gmx.de> wrote: >> >>> 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/[http://www.manning.com/bauer3/]> >> JUnit in Action, Second Edition >> <http://www.manning.com/tahchiev/[http://www.manning.com/tahchiev/]> >> Spring Batch in Action >> <http://www.manning.com/templier/[http://www.manning.com/templier/]> >> Blog: http://garygregory.wordpress.com[http://garygregory.wordpress.com] >> Home: http://garygregory.com/[http://garygregory.com/] >> Tweet! http://twitter.com/GaryGregory[http://twitter.com/GaryGregory] > > -- > Von meinem Telefon gesendet. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
