[ https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989095#comment-12989095 ]
Bernhard Reichl commented on VFS-309: ------------------------------------- In the case of getting a zip file the workaround with DefaultFileContent.close() does not work as for all files within the zip file the ThreadLocal object is still valid and will not deleted by gc. > 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.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 is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira