[ https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149797#comment-13149797 ]
jontro commented on VFS-309: ---------------------------- This is still an issue. Why even store it in a ThreadLocal at all, it could be implemented with a custom class for storing it like described in this article: http://blog.maxant.co.uk/pebble/2008/09/23/1222200780000.html It also would be nice to be able to clear this per thread after a request has been made in a request filter. > 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira