[
https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495724
]
Adam Heath commented on VFS-142:
--------------------------------
It's not just the object itself, but everything it references. It references
DefaultFileContent, which references AbstractFileObject, which references
AbstractFileSystem. Then, if you have layered file systems, DelegateFileObject
comes into play, which has it's own references.
I've got several layered file system implementations(one, that stores
attributes as foo@/attr-name, and another, that implements COW(copy-on-write);
yet another that does *proper* virtual mounts, meaning nested).
When the top-level file is a DelegateFileObject, from VirtualFileSystem, the
whole chain of references underneath it gets very large.
I spent a great deal of time just a week ago chasing down memory usage. This
was a fairly large segment of memory freed up by this. Most of the memory
issues I ended up fixing were in commons-vfs; most were looped references being
held in static fields(ThreadLocal is a global static field, so always maintains
it's references).
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
