[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlbeans-dev
Subject: [jira] [Updated] (XMLBEANS-502) Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat
From: "Christopher Brown (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date: 2013-06-27 7:30:21
Message-ID: JIRA.12655084.1372318049006.178860.1372318221428 () arcas
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/XMLBEANS-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]
Christopher Brown updated XMLBEANS-502:
---------------------------------------
Description:
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.
was:
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?
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic