Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-450

Tomcat reports SEVERE ThreadLocal issues upon shutdown

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.18
    • Fix Version/s: 0.9.26
    • Component/s: None
    • Labels:
      None
    • Environment:

      Tomcat 6.0.24, JDK 6, Windows or Solaris

      Description

      I have a webapp that uses Logback, deployed on a Tomcat instance. Upon shutdown, Tomcat reports this and doesn't completely shut down:

      SEVERE: A web application created a ThreadLocal with key of type [org.slf4j.impl.CopyOnInheritThreadLocal] (value [org.slf4j.impl.CopyOnInheritThreadLocal@1bb35
      b]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
      Feb 3, 2010 10:49:22 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
      SEVERE: A web application created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@10e2558]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.

      Is LogBack leaking resources?

        Activity

        Hide
        carey Carey Evans added a comment -

        A fix for this warning is to change guard.set(false) on line 98 of UnsynchronizedAppenderBase.java to guard.remove().

        However, this may make things slower since (on Java 6) it causes rehashing of the ThreadLocalMap twice every time doAppend() is called. A better solution may be to not override ThreadLocal.initialValue(), so that the ThreadLocalMap keys don't refer indirectly to the web application's ClassLoader, checking whether guard.get() returns null on line 70 instead: Boolean.TRUE.equals(guard.get()).

        Since Boolean comes from the system ClassLoader, the ThreadLocalMap values never refer to the web application's ClassLoader.

        Show
        carey Carey Evans added a comment - A fix for this warning is to change guard.set(false) on line 98 of UnsynchronizedAppenderBase.java to guard.remove(). However, this may make things slower since (on Java 6) it causes rehashing of the ThreadLocalMap twice every time doAppend() is called. A better solution may be to not override ThreadLocal.initialValue(), so that the ThreadLocalMap keys don't refer indirectly to the web application's ClassLoader, checking whether guard.get() returns null on line 70 instead: Boolean.TRUE.equals(guard.get()). Since Boolean comes from the system ClassLoader, the ThreadLocalMap values never refer to the web application's ClassLoader.
        Hide
        noreply.ceki@qos.ch Ceki Gulcu added a comment - - edited

        Carey,

        After testing if overriding tyhreadLocal.initialValue() changes anything, in particular with respect to ThreadLocalMap referring to the web-app's class loader, I can confirm that it does the trick, i.e. makes Tomcat happy.

        Show
        noreply.ceki@qos.ch Ceki Gulcu added a comment - - edited Carey, After testing if overriding tyhreadLocal.initialValue() changes anything, in particular with respect to ThreadLocalMap referring to the web-app's class loader, I can confirm that it does the trick, i.e. makes Tomcat happy.
        Hide
        noreply.ceki@qos.ch Ceki Gulcu added a comment -
        Show
        noreply.ceki@qos.ch Ceki Gulcu added a comment - Solved in http://github.com/ceki/logback/commit/13500debebe
        Hide
        fonsito Fonsito added a comment -

        Having the same problem in 0.9.26 and 0.9.28 with java 1.6.0_22, in tomcat 6.0.29.

        SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@e42ace]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
        01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap

        SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@1b64a3a]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
        01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap

        SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@c330f8]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
        01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap

        Thanks for any suggestion.

        Show
        fonsito Fonsito added a comment - Having the same problem in 0.9.26 and 0.9.28 with java 1.6.0_22, in tomcat 6.0.29. SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@e42ace] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@1b64a3a] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/application] created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@c330f8] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 01-feb-2011 17:45:07 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap Thanks for any suggestion.
        Hide
        nina256 Nin Enska added a comment -

        Hi, I am having the same problem:

        28-Sep-2016 18:09:53.883 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@75935153]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
        28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@1e12761]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
        28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@f0dcfd2]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
        28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@69b9bdfd]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

        I am using:
        ch.qos.logback:logback-classic:jar:1.1.7 , ch.qos.logback:logback-core:jar:1.1.7, tomcat 8.0.11

        This ticket says the fix was in version 0.9.26 - so this actually shouldn't happen?

        Show
        nina256 Nin Enska added a comment - Hi, I am having the same problem: 28-Sep-2016 18:09:53.883 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@75935153] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@1e12761] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@f0dcfd2] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 28-Sep-2016 18:09:53.884 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application [] created a ThreadLocal with key of type [ch.qos.logback.core.UnsynchronizedAppenderBase$1] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@69b9bdfd] ) and a value of type [java.lang.Boolean] (value [false] ) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. I am using: ch.qos.logback:logback-classic:jar:1.1.7 , ch.qos.logback:logback-core:jar:1.1.7, tomcat 8.0.11 This ticket says the fix was in version 0.9.26 - so this actually shouldn't happen?

          People

          • Assignee:
            noreply.ceki@qos.ch Ceki Gulcu
            Reporter:
            awhitford Anthony Whitford
          • Votes:
            11 Vote for this issue
            Watchers:
            15 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: