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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
