You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Peter (JIRA)" <ji...@apache.org> on 2018/04/21 14:39:00 UTC

[jira] [Commented] (CXF-6749) Classloader leak on FileUtils.createTmpDir()

    [ https://issues.apache.org/jira/browse/CXF-6749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446836#comment-16446836 ] 

Peter commented on CXF-6749:
----------------------------

maybeDeleteDefaultTempDir causes an IllegalStateException if it tries to remove the shutdown hook while the JVM is already shutting down.  I have seen this error in Jetty after a failsafe junit validation test suite finishes.  

I was going to suggest passing a shutdown flag from CXFNonSpringServlet.destroy via AbstractHTTPServlet.destroy to FileUtils.maybeDeleteDefaultTempDir to indicate shutdown in progess, but it seems like FileUtils.maybeDeleteDefaultTempDir is only called during shutdown.  Is removing the shutdown hook necessary?

> Classloader leak on FileUtils.createTmpDir()
> --------------------------------------------
>
>                 Key: CXF-6749
>                 URL: https://issues.apache.org/jira/browse/CXF-6749
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.7.14
>         Environment: Slackware Linux 14.1 (kernel 3.10.17), Java 1.7.0_75, Tomcat 7.0.39 (this is my production environment)
>            Reporter: Diogo Sant'Ana
>            Assignee: Daniel Kulp
>            Priority: Major
>              Labels: classloader-leak
>             Fix For: 3.1.5, 3.0.8
>
>
> FileUtils.createTmpDir() adds a ApplicationShutdownHook to remove the recently created temp folder, creating a indirect reference to the Tomcat WebappClassloader from the hook static attribute at ApplicationShutdownHooks class, preventing the classloader to be collected.
> Actually, it will be collected when the JVM is turned off. But this is a web application container, it won't be turn off for a while.
> I only checked this with the version I´m currently using (2.7.14), but I checked the code at 3.1.x and master branches and it still the same.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)