jaxb
  1. jaxb
  2. JAXB-831

Memory leak in com.sun.xml.bind.v2.ClassFactory

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.2.2
    • Fix Version/s: 2.2.4u2, 2.2.5
    • Component/s: runtime
    • Labels:
      None

      Description

      I get the following error message from Tomcat on redeploying my webapp:

      02.05.2011 18:26:13 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
      SCHWERWIEGEND: The web application [/foo] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@54b8cdc]) and a value of type [java.util.WeakHashMap] (value [

      {class javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@5af92541}

      ]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

      I.e. Tomcat tries to clean up after the applications deployed on it, but the problem is really in the application and not in Tomcat. My application creates a JAXBContext on startup. JAXBContext has no destroy() method, so I'd expect is to do its own cleanup.

      This is really a duplicate of JAXB-563, but I do not have the permission to reopen that bug.

      Reviewing the source code of com.sun.xml.bind.v2.ClassFactory, it is easy to see that this class creates a static private ThreadLocal storage and never calls remove() on the ThreadLocal, so this is clearly the root cause of the problem.

        Activity

        Hide
        melihcelik added a comment -

        This issue seems to be resolved but is it completed, is it in the product and if so, on which version is it fixed? Because I do have the same problem with 2.2.1.1 version of jaxb-impl.

        Show
        melihcelik added a comment - This issue seems to be resolved but is it completed, is it in the product and if so, on which version is it fixed? Because I do have the same problem with 2.2.1.1 version of jaxb-impl.
        Hide
        pand added a comment -

        It still happen with jaxb-impl 2.2.6 which is a direct dependency jaxws-rt 2.2.7
        Any chance to solve this?

        Show
        pand added a comment - It still happen with jaxb-impl 2.2.6 which is a direct dependency jaxws-rt 2.2.7 Any chance to solve this?
        Hide
        Iaroslav Savytskyi added a comment -

        Hi, all,

        If it's possible to reproduce this - please create some testCase and we'll try to fix it.

        Show
        Iaroslav Savytskyi added a comment - Hi, all, If it's possible to reproduce this - please create some testCase and we'll try to fix it.
        Hide
        zakath added a comment -

        It seems to be pretty consistent if you have an application using JaxB deployed in a Tomcat environment. For us it's web service proxy clients using Apache CXF, so I'm not quite sure how to go about writing a minimal testcase for it.

        The problem is compounded in a Tomcat environment because you have no idea which thread will run your request, and you also get one instance of the cache for every thread which happens to use JaxB. It is possible to clean up after use by calling ClassFactory.clearCache(), either after you're done unmarshalling the XML or in a ServletRequestListener after your servlet is done. The problem is of course that this reduces the advantage of having a cache in the first place.

        One fix might be to just change it to a static map instead of a ThreadLocal map, class definitions aren't exactly likely to change depending on the executing thread.

        Show
        zakath added a comment - It seems to be pretty consistent if you have an application using JaxB deployed in a Tomcat environment. For us it's web service proxy clients using Apache CXF, so I'm not quite sure how to go about writing a minimal testcase for it. The problem is compounded in a Tomcat environment because you have no idea which thread will run your request, and you also get one instance of the cache for every thread which happens to use JaxB. It is possible to clean up after use by calling ClassFactory.clearCache(), either after you're done unmarshalling the XML or in a ServletRequestListener after your servlet is done. The problem is of course that this reduces the advantage of having a cache in the first place. One fix might be to just change it to a static map instead of a ThreadLocal map, class definitions aren't exactly likely to change depending on the executing thread.
        Hide
        Nameless added a comment -

        Faced this issue with JAXB 2.2.3, added explicit Maven dependency to 2.2.5. War contains library with fix, but issue still reproduces:

        30-Apr-2013 15:25:01.677 SEVERE [tomcat-http--3] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@13c27c22]) and a value of type [java.util.WeakHashMap] (value [

        {class javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@4563a650}

        ]) 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.

        Any advice is appreciated.

        Show
        Nameless added a comment - Faced this issue with JAXB 2.2.3, added explicit Maven dependency to 2.2.5. War contains library with fix, but issue still reproduces: 30-Apr-2013 15:25:01.677 SEVERE [tomcat-http--3] org.apache.catalina.loader.WebappClassLoader.checkThreadLocalMapForLeaks The web application created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@13c27c22] ) and a value of type [java.util.WeakHashMap] (value [ {class javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@4563a650} ]) 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. Any advice is appreciated.

          People

          • Assignee:
            Martin Grebac
            Reporter:
            Harald Wellmann
          • Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: