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
