[
https://issues.apache.org/jira/browse/CXF-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565279#comment-13565279
]
Gediminas Rimša commented on CXF-4529:
--------------------------------------
This is still an issue in parallel deployment setup (when there are multiple
versions of the same application running at times). When a new instance of
application calls CXFAuthenticator.addAuthenticator(), it wraps the
ReferencingAuthenticator from the previous application instance, thus
preventing its classloader from being garbage collected later.
After a few such deployments, the GC roots of the first undeployed application
classloader (which should be garbage collected) look like this:
{noformat}
this - value:
org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader
#7
<- classloader - class: java.security.ProtectionDomain, value:
org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader
#7
<- [3] - class: java.security.ProtectionDomain[], value:
java.security.ProtectionDomain #575
<- context - class: java.security.AccessControlContext, value:
java.security.ProtectionDomain[] #8 (21 items)
<- acc - class: java.net.URLClassLoader, value:
java.security.AccessControlContext #11
<- <classLoader> - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
java.net.URLClassLoader #4
<- <class> - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator class
ReferencingAuthenticator
<- wrapped - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- wrapped - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- wrapped - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- wrapped - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- wrapped - class:
org.apache.cxf.transport.http.ReferencingAuthenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- theAuthenticator - class: java.net.Authenticator, value:
org.apache.cxf.transport.http.ReferencingAuthenticator #1
<- [14507] - class: java.lang.Object[], value:
java.net.Authenticator class Authenticator
<- elementData - class: java.util.Vector, value:
java.lang.Object[] #196029 (20 480 items)
<- classes - class:
org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader,
value: java.util.Vector #15121
<- contextClassLoader (thread object) - class:
java.lang.Thread, value:
org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader
#1
{noformat}
> PermGen Leak for CXFAuthenticator (WS Client Configuration)
> -----------------------------------------------------------
>
> Key: CXF-4529
> URL: https://issues.apache.org/jira/browse/CXF-4529
> Project: CXF
> Issue Type: Bug
> Components: Configuration, JAX-WS Runtime
> Affects Versions: 2.6.1
> Environment: Apache Tomcat 7, Windows 7 32bit
> Reporter: Holger Sunke
> Assignee: Daniel Kulp
> Labels: leak, permgen
> Fix For: 2.7.1
>
>
> Hello,
> seemes to me there is a memory leak with the CXFAuthenticator. There is a
> static reference to it in java.net.Authenticator.theAuthenticator .
> This prevents the GC from collecting the WebappClassLoader on hot
> undeployment.
> I helped myself by doing
> java.net.Authenticator.setDefault(null);
> on contextDestroy().
> Our web application uses CXF as a jasWS client configured with Spring 3.0.5.
--
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
