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:06:16 UTC
[jira] Created: (VFS-143) Fix memory leak in DelegateFileObject in
it's handling of listeners
Fix memory leak in DelegateFileObject in it's handling of listeners
-------------------------------------------------------------------
Key: VFS-143
URL: https://issues.apache.org/jira/browse/VFS-143
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.1
Reporter: Adam Heath
DelegateFileObject adds itself as a listener to the wrapped file. This adds a *hard* reference to the DelegateFileObject, which prevents it from being garbaged collected. So, create a WeakRefFileListener proxy, to solve the problem.
--
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
Re: [jira] Created: (VFS-143) Fix memory leak in DelegateFileObject
in it's handling of listeners
Posted by "marius.cimpean" <ma...@numerica.de>.
Hi,
It looks like the patch doesn't solve the memory-leak problem for all.
I am using commons-vfs to copy huge amount of files into a specific location
- I use VirtualFileSystem.
I am running a memory analyzer and I am able to see that inside of
org.apache.commons.vfs.provider.AbstractFileSystem class, there is a the
listenerMap that holds instances of WeakRefFileListener. It looks like the
WeakRefFileListener instances are never garbage collected and the
listenerMap gets never released - so the memory still remains occupied.
Basically, when dealing with huge amount of data there are two large maps
that holds instances related to commons-vfs internal stuff. The two maps are
:
- org.apache.commons.vfs.provider.AbstractFileSystem.listenerMap - never
gets released ==> OutOfMemory
- org.apache.commons.vfs.cache.SoftRefFilesCache.refReverseMap - it gets
released
Please let me know the right way that commons-vfs shall release its internal
resources (specially the listeners map I pointed above) in order to avoid
memory leaks and OutOfMemory situations.
Best Regards,
Marius
--
View this message in context: http://www.nabble.com/-jira--Created%3A-%28VFS-143%29-Fix-memory-leak-in-DelegateFileObject-in-it%27s-handling-of-listeners-tp10604517p20208819.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[jira] Updated: (VFS-143) Fix memory leak in DelegateFileObject in
it's handling of listeners
Posted by "Adam Heath (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Heath updated VFS-143:
---------------------------
Attachment: fix_DelegateFile-listener-leak.patch
Against svn 501759.
> Fix memory leak in DelegateFileObject in it's handling of listeners
> -------------------------------------------------------------------
>
> Key: VFS-143
> URL: https://issues.apache.org/jira/browse/VFS-143
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Adam Heath
> Attachments: fix_DelegateFile-listener-leak.patch
>
>
> DelegateFileObject adds itself as a listener to the wrapped file. This adds a *hard* reference to the DelegateFileObject, which prevents it from being garbaged collected. So, create a WeakRefFileListener proxy, to solve the problem.
--
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