[
https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993082#comment-13993082
]
Ryan Boettcher commented on VFS-142:
------------------------------------
Just to add to what Adam is saying; over here in my group's environment we are
currently using vfs in dropwizard app (uses thread pool for connections so the
threads stick around basically forever) to access a filesystem which (for
various technical reasons) is several levels deep and has potentially thousands
of subdirs and/or files under each dir in the tree, so every leaked filesystem
in our case leaves well over 100MB of unrecoverable memory linked to nothing
but the thread.
With potentially each filesystem leaked multiple times in every pooled thread
what this means, in practice (ie. our production environment), is this leak
eats up about 4GB of server memory at least twice a week, which is very
annoying.
We're currently working around the problem by threading all our file
operations, but this is very undesirable and we don't want to keep this
workaround in production for long.
> Clear ThreadData after all streams are closed, fixes a memory leak
> ------------------------------------------------------------------
>
> Key: VFS-142
> URL: https://issues.apache.org/jira/browse/VFS-142
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Adam Heath
> Attachments: fix_ThreadData-clear.patch
>
>
> After all streams are closed in FileContentThreadData, clear the ThreadLocal.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
