You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Adam Heath (JIRA)" <ji...@apache.org> on 2007/05/14 16:00:21 UTC
[jira] Created: (VFS-142) Clear ThreadData after all streams are
closed, fixes a memory leak
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
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (VFS-142) Clear ThreadData after all streams are
closed, fixes a memory leak
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (VFS-142) Clear ThreadData after all streams are
closed, fixes a memory leak
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Heath updated VFS-142:
---------------------------
Attachment: fix_ThreadData-clear.patch
Against svn 501759.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (VFS-142) Clear ThreadData after all streams are
closed, fixes a memory leak
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495613 ]
Mario Ivankovits commented on VFS-142:
--------------------------------------
Is it really worth the hassle?
Having the FileContentThreadData around in an ThreadLocal might not necessarily introduce a memory leak and the object itself is not that big, two array lists and one reference.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org