cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattias Jiderhamn (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5442) CXFAuthenticator causes classloader leaks
Date Sat, 07 Dec 2013 07:25:35 GMT

     [ https://issues.apache.org/jira/browse/CXF-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mattias Jiderhamn updated CXF-5442:
-----------------------------------

    Description: 
org.apache.cxf.transport.http.CXFAuthenticator will cause classloader leaks.

When CXFAuthenticator.addAuthenticator() is called, org.apache.cxf.transport.http.ReferencingAuthenticator
is instantiated in a custom "dummy" URLClassLoader, and then wraps any pre-existing default
Authenticator + weak references the CXFAuthenticator.

In theory, this means that the classloader loading the CXFAuthenticator can be garbage collected,
and then ReferencingAuthenticator.auth is cleared since CXFAuthenticator.instance is not strongly
reachable from GC root.

I won't say my conclusions are final, but this is how I think it happens: When the dummy URLClassLoader
is instantiated, it inherits the ProtectionDomain that references the current classloader,
which is the one that loaded CXFAuthenticator and thus there is a path to GC root (see screenshot)
and the web app classloader is never garbage collected.

  was:
org.apache.cxf.transport.http.CXFAuthenticator will cause classloader leaks.

When CXFAuthenticator.addAuthenticator() is called, org.apache.cxf.transport.http.ReferencingAuthenticator
is instantiated in a custom "dummy" URLClassLoader, and then wraps any pre-existing default
Authenticator + weak references the CXFAuthenticator.

In theory, this means that the classloader loading the CXFAuthenticator can be garbage collected,
and then ReferencingAuthenticator.auth is cleared since CXFAuthenticator.instance is not strongly
reachable from GC root.

I won't say my conclusions are final, but this is how I think it happens: When the dummy URLClassLoader
is instantiated, it inherits the AccessControlContext that references the current classloader,
which is the one that loaded CXFAuthenticator and thus there is a path to GC root (see screenshot)
and the web app classloader is never garbage collected.


> CXFAuthenticator causes classloader leaks
> -----------------------------------------
>
>                 Key: CXF-5442
>                 URL: https://issues.apache.org/jira/browse/CXF-5442
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.6.10
>            Reporter: Mattias Jiderhamn
>         Attachments: cxf.jpg
>
>
> org.apache.cxf.transport.http.CXFAuthenticator will cause classloader leaks.
> When CXFAuthenticator.addAuthenticator() is called, org.apache.cxf.transport.http.ReferencingAuthenticator
is instantiated in a custom "dummy" URLClassLoader, and then wraps any pre-existing default
Authenticator + weak references the CXFAuthenticator.
> In theory, this means that the classloader loading the CXFAuthenticator can be garbage
collected, and then ReferencingAuthenticator.auth is cleared since CXFAuthenticator.instance
is not strongly reachable from GC root.
> I won't say my conclusions are final, but this is how I think it happens: When the dummy
URLClassLoader is instantiated, it inherits the ProtectionDomain that references the current
classloader, which is the one that loaded CXFAuthenticator and thus there is a path to GC
root (see screenshot) and the web app classloader is never garbage collected.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message