[
https://issues.apache.org/jira/browse/CXF-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188401#comment-13188401
]
Denis Delangle commented on CXF-4006:
-------------------------------------
I am having the same kind of issue under Tomcat which is the client, not the
server. After undeploying my webapp, I have this message from Tomcat :
{quote}
GRAVE: The web application [/sipbo] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@327958ef]) and a value of
type [org.apache.cxf.jaxrs.ext.MessageContextImpl] (value
[org.apache.cxf.jaxrs.ext.MessageContextImpl@3cbdcccc]) 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.
{quote}
I am creating my client code like this :
{code:java}
//I create my delegate instance lazily
private NotificationService getDelegate() {
if (delegate == null) {
delegate = JAXRSClientFactory.create(url,
NotificationService.class, new ArrayList<Object>(), true);
}
}
//I try to destroy the client when shutting down the webapp
@PreDestroy
public void cleanResources() {
WebClient.getConfig(delegate).getBus().shutdown(true);
}
{code}
After searching with VisualVM, it seems that instances of MesageContextImpl are
still stored in a ThreadLocalMessageContext referenced in the static field
AbstractResourceInfo.setterProxyMap and in the instance field
JAXBElementProvider.mc.
It can be a misuse of the API or it may help solve the bug.
> Possible classloader leak due to ThreadLocal
> --------------------------------------------
>
> Key: CXF-4006
> URL: https://issues.apache.org/jira/browse/CXF-4006
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.5.1
> Environment: Glassfish
> OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-61.1.10.4.fc16-x86_64)
> Reporter: Art O Cathain
>
> org.apache.cxf.jaxrs.ext.MessageContextImpl is kept in a ThreadLocal for each
> HTTP request which means when a CXF-servlet-based webapp is undeployed, the
> webapp's classloader leaks.
> (At least, I think that's what's going on, I'm not that expert at tracking
> down memory leaks. Perhaps I have misconfigured something?)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
