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/> >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 -- Von meinem Telefon gesendet.
