commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels (JIRA)" <>
Subject [jira] [Updated] (VFS-309) ThreadLocal memory leak in DefaultFileContent
Date Tue, 02 Dec 2014 17:17:12 GMT


Bernd Eckenfels updated VFS-309:
    Attachment: close-on-close.patch

This close-on-close.patch does deal wit removing ThreadLocalState when only (all) streams
are closed but not Filecontent.close(). It also reduces generation of new threadlocals a bit
and synchronizes state changes. It also makes sure the FileContent.close() always tries to
close all streams before reporting an error. What do you think?

> ThreadLocal memory leak in DefaultFileContent
> ---------------------------------------------
>                 Key: VFS-309
>                 URL:
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0
>         Environment: Tomcat servlet container
>            Reporter: jontro
>            Priority: Blocker
>             Fix For: 2.1
>         Attachments: close-on-close.patch, threadlocal_setNull_vs_remove_bug.patch
> When using commons vfs in a servlet container the ThreadLocal values stored will not
be released once the request finishes.
> There needs to be a method to clear these values otherwise the data will leak into the
next request.
> This was detected with tomcat 6.0.26. Upon undeploying an app that uses commons vfs tomcat
detects the leaks with a huge amount of the following messages:
> A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal@52fb241d]) and a value of type [org.apache.commons.vfs.provider.FileContentThreadData]
(value [org.apache.commons.vfs.provider.FileContentThreadData@6600167a]) but failed to remove
it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been
forcibly removed.

This message was sent by Atlassian JIRA

View raw message