You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Gediminas Rimša (JIRA)" <ji...@apache.org> on 2013/01/29 12:01:12 UTC
[jira] [Commented] (CXF-4529) PermGen Leak for CXFAuthenticator (WS
Client Configuration)
[ 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