[
https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927427#action_12927427
]
Ralph Goers commented on VFS-309:
---------------------------------
DefaultFileContent.close() will remove the ThreadData, however a subsequent
call to isOpen() would proceed to add a new Object to the ThreadLocal since
getThreadData() unconditionally adds one.
> ThreadLocal memory leak in DefaultFileContent
> ---------------------------------------------
>
> Key: VFS-309
> URL: https://issues.apache.org/jira/browse/VFS-309
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Tomcat servlet container
> Reporter: jontro
>
> 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.threadlo...@52fb241d]) and a value
> of type [org.apache.commons.vfs.provider.FileContentThreadData] (value
> [org.apache.commons.vfs.provider.filecontentthreadd...@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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
