jaxb
  1. jaxb
  2. JAXB-1000

com.sun.xml.bind.v2.ClassFactory has memory leak

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.6, 2.2.7
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Tomcat 7

      Description

      This error is seen in tomcat 7 logs:

      SEVERE: The web application [/secportal] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@301013d6]) and a value of type [java.util.WeakHashMap]

      This is caused by JAXB creating but never clearing a ThreadLocal of type ClassFactory.

        Activity

        Hide
        herman.bovens added a comment -

        Apparently there was JAXB-831 for an earlier version, but it seems it was never really resolved. I can't reopen that bug.
        I don't know if it's possible at all to create a test case for it. If no thread pooling is done, this isn't really an issue, but it is in application servers like Tomcat.

        Show
        herman.bovens added a comment - Apparently there was JAXB-831 for an earlier version, but it seems it was never really resolved. I can't reopen that bug. I don't know if it's possible at all to create a test case for it. If no thread pooling is done, this isn't really an issue, but it is in application servers like Tomcat.
        Hide
        Iaroslav Savytskyi added a comment -

        You are absolutely right. Unfortunately JAXB doesn't have any chance to clean up caches. Simply because in API we don't have any 'finalization' process.

        To avoid this bug Martin changed com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl signature and make is closeable. So in your code when you are done call close on your unmarshaller instance.

        Thanks.

        Show
        Iaroslav Savytskyi added a comment - You are absolutely right. Unfortunately JAXB doesn't have any chance to clean up caches. Simply because in API we don't have any 'finalization' process. To avoid this bug Martin changed com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl signature and make is closeable. So in your code when you are done call close on your unmarshaller instance. Thanks.
        Hide
        jhrobbin added a comment -

        I am running into this issue and see that it has been reported several times over many years (JAXB-1000, JAXB-831, and JAXB-563).

        Is this SEVERE warning something that can be ignored? Perhaps only affecting redploy of a war to Tomcat, where the previous classloader cannot be GC'd. Or is it a true memory leak in a running application that needs to be resolved?

        @Iaroslav, can you suggest how I might close the unmarshaller instance using Jersey/JAXB/Spring?

        Show
        jhrobbin added a comment - I am running into this issue and see that it has been reported several times over many years ( JAXB-1000 , JAXB-831 , and JAXB-563 ). Is this SEVERE warning something that can be ignored? Perhaps only affecting redploy of a war to Tomcat, where the previous classloader cannot be GC'd. Or is it a true memory leak in a running application that needs to be resolved? @Iaroslav, can you suggest how I might close the unmarshaller instance using Jersey/JAXB/Spring?
        Hide
        hartmannt added a comment -

        I have the same issue with apache-tomcat-7.0.55 and JAXWS 2.2.8 which includes JAXB-2.2.7 (Java is 1.7.0_51b13 on Win7 64bit)

        Aug 28, 2014 6:03:28 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
        SEVERE: The web application [/xxxx] created a ThreadLocal 
        with key of type [com.sun.xml.bind.v2.ClassFactory$1] 
        (value [com.sun.xml.bind.v2.ClassFactory$1@313f20fb]) 
        and a value of type [java.util.WeakHashMap] 
        (value [{class com...=java.lang.ref.WeakReference@486219fa, ...]) 
        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.
        
        Show
        hartmannt added a comment - I have the same issue with apache-tomcat-7.0.55 and JAXWS 2.2.8 which includes JAXB-2 .2.7 (Java is 1.7.0_51b13 on Win7 64bit) Aug 28, 2014 6:03:28 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/xxxx] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1] (value [com.sun.xml.bind.v2.ClassFactory$1@313f20fb]) and a value of type [java.util.WeakHashMap] (value [{class com...=java.lang.ref.WeakReference@486219fa, ...]) 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.
        Hide
        Iaroslav Savytskyi added a comment -

        @jhrobbin I think if you are using JAXB directly (have access to Unmarshaller instance) than you have a chance to deal with it. In other case - I don't have any other ideas.

        Show
        Iaroslav Savytskyi added a comment - @jhrobbin I think if you are using JAXB directly (have access to Unmarshaller instance) than you have a chance to deal with it. In other case - I don't have any other ideas.
        Hide
        Iaroslav Savytskyi added a comment -

        Until JAXB API change we are not able to deal with this.

        Show
        Iaroslav Savytskyi added a comment - Until JAXB API change we are not able to deal with this.
        Hide
        gavenkoa added a comment -

        I have same WARNING in catalina.log for Tomcat 8. After investigating issue with VidualVM I find nearest root to GC looks like:

        this - value: org.apache.catalina.loader.WebappClassLoader #3
        <- <classLoader> - class: com.sun.xml.bind.DatatypeConverterImpl, value: org.apache.catalina.loader.WebappClassLoader #3
        <- <class> - class: com.sun.xml.bind.DatatypeConverterImpl, value: com.sun.xml.bind.DatatypeConverterImpl class DatatypeConverterImpl
        <- theConverter (sticky class) - class: javax.xml.bind.DatatypeConverter, value: com.sun.xml.bind.DatatypeConverterImpl #1

        Quick search shown that this problem comes from com.sun.xml.bind:jaxb-impl package. Because Java 7 include own implementation (JAXB RI) I just exclude that package from dependencies:

        <dependency>
        <groupId>com.sun.jersey</groupId>
        <artifactId>jersey-json</artifactId>
        <version>$

        {jersey.version}

        </version>
        <exclusions>
        <exclusion>
        <groupId>com.sun.xml.bind</groupId>
        <artifactId>jaxb-impl</artifactId>
        </exclusion>
        </exclusions>
        </dependency>

        See more at http://stackoverflow.com/questions/11361036/javax-xml-bind-datatypeconverter-leaking-class-loaders/

        Show
        gavenkoa added a comment - I have same WARNING in catalina.log for Tomcat 8. After investigating issue with VidualVM I find nearest root to GC looks like: this - value: org.apache.catalina.loader.WebappClassLoader #3 <- <classLoader> - class: com.sun.xml.bind.DatatypeConverterImpl, value: org.apache.catalina.loader.WebappClassLoader #3 <- <class> - class: com.sun.xml.bind.DatatypeConverterImpl, value: com.sun.xml.bind.DatatypeConverterImpl class DatatypeConverterImpl <- theConverter (sticky class) - class: javax.xml.bind.DatatypeConverter, value: com.sun.xml.bind.DatatypeConverterImpl #1 Quick search shown that this problem comes from com.sun.xml.bind:jaxb-impl package. Because Java 7 include own implementation (JAXB RI) I just exclude that package from dependencies: <dependency> <groupId>com.sun.jersey</groupId> <artifactId>jersey-json</artifactId> <version>$ {jersey.version} </version> <exclusions> <exclusion> <groupId>com.sun.xml.bind</groupId> <artifactId>jaxb-impl</artifactId> </exclusion> </exclusions> </dependency> See more at http://stackoverflow.com/questions/11361036/javax-xml-bind-datatypeconverter-leaking-class-loaders/

          People

          • Assignee:
            Iaroslav Savytskyi
            Reporter:
            herman.bovens
          • Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: