[ 
https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125315#comment-14125315
 ] 

Marceau Dewilde commented on XMLBEANS-502:
------------------------------------------

We use XMLBeans in a reasonably large webapp. We checked and XMLBeans is 
responsible for at least 90% of the resource leaks since July 2013. These have 
caused production servers to come down after redeploys (classes can not be 
unloaded because ThreadLocals are not correctly cleaned up).
Is there any chance of this issue being looked at and hopefully resolved?

Some samples:
catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a 
ThreadLocal with key of type 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a value of 
type java.util.ArrayList (value java.lang.ref.SoftReference@22e0750f) 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.
catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a 
ThreadLocal with key of type org.apache.xmlbeans.impl.store.CharUtil$1 (value 
org.apache.xmlbeans.impl.store.CharUtil$1@32c00f6e) and a value of type 
java.lang.ref.SoftReference (value java.lang.ref.SoftReference@3e253dac) 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.
catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created a 
ThreadLocal with key of type 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value 
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a value of 
type java.util.ArrayList (value java.lang.ref.SoftReference@7ef40713) 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.


> Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF
> -----------------------------------------------------------------------------
>
>                 Key: XMLBEANS-502
>                 URL: https://issues.apache.org/jira/browse/XMLBEANS-502
>             Project: XMLBeans
>          Issue Type: Bug
>    Affects Versions:  Version 2.3
>         Environment: Apache Tomcat 6.0.35, Apache POI 3.9-20121203, Java SE 
> 6/7, any operating system
>            Reporter: Christopher Brown
>         Attachments: leak1.png, leak2.png
>
>
> Hello,
> After creating this issue 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55149 I was advised to 
> create the issue here.  This appears to be similar to 
> https://issues.apache.org/jira/browse/XMLBEANS-103 but as it's marked as 
> FIXED and as I'm using a more recent version (and as it's not completely 
> identical), I'm creating a new issue.
> It would appear that XMLBeans is creating (and not clearing) ThreadLocal 
> variables.  This causes Tomcat to complain about classloader leaks (see 
> messages below).  Based on information in XMLBEANS-103, I have tried to coax 
> the JVM to clear the ThreadLocal (by performing garbage collection on the 
> JVM), but that doesn't clear the ThreadLocals, even if allowing time to 
> elapse AFTER using POI to process an XSSF document and BEFORE stopping Tomcat.
> To workaround this, we're having to impose long downtime when a restart is 
> required.  Perhaps a utility class within XMLBeans could be made available 
> with the POI distribution such as:
> XMLBeansCache.clearThreadLocals()
> ...that I could call from a "finally" block after processing the XSSF 
> document?
> Here's the information from Tomcat's logs:
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type 
> [org.apache.xmlbeans.XmlBeans$1] (value 
> [org.apache.xmlbeans.XmlBeans$1@7d3aace]) and a value of type 
> [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@5972be65]) 
> but failed to remove it when the web application was stopped. This is very 
> likely to create a memory leak.
> Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader 
> clearThreadLocalMap
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type 
> [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1] (value 
> [org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@7c3206c3]) and a 
> value of type [java.util.ArrayList] (value 
> [[java.lang.ref.SoftReference@385a2be8]]) but failed to remove it when the 
> web application was stopped. This is very likely to create a memory leak.
> Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader 
> clearThreadLocalMap
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type 
> [org.apache.xmlbeans.impl.store.Locale$1] (value 
> [org.apache.xmlbeans.impl.store.Locale$1@27f8a93f]) and a value of type 
> [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@362f7b99]) 
> but failed to remove it when the web application was stopped. This is very 
> likely to create a memory leak.
> Jun 26, 2013 7:01:56 PM org.apache.catalina.loader.WebappClassLoader 
> clearThreadLocalMap
> SEVERE: The web application [/foobar] created a ThreadLocal with key of type 
> [org.apache.xmlbeans.impl.store.CharUtil$1] (value 
> [org.apache.xmlbeans.impl.store.CharUtil$1@675b9599]) and a value of type 
> [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@2dbaa4d2]) 
> but failed to remove it when the web application was stopped. This is very 
> likely to create a memory leak.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org

Reply via email to