Björn Persson Mattsson created VFS-633:
------------------------------------------
Summary: Memory/reference leak when handling tar.gz-files
Key: VFS-633
URL: https://issues.apache.org/jira/browse/VFS-633
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Windows, Red Hat Linux
Reporter: Björn Persson Mattsson
When using VFS to process a large amount of tar.gz-archives there is a memory
leak occurring where the references to a lot of TarArchiveEntry and
TarFileObject objects are never released. This ultimately leads to an
OutOfMemoryError.
After using NetBeans profiler to trace where the persistent objects are
created, it seems like they originate from calls to
`VFS.getManager().resolveFile("tgz://" + filePath)`. The method traces returned
from the profiler are shown below:
org.apache.commons.compress.archivers.tar.TarArchiveEntry
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry
()
org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
(Comparable, org.apache.commons.vfs2.FileSystem)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
(String, org.apache.commons.vfs2.FileObject,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
org.apache.commons.vfs2.provider.tar.TarFileObject
org.apache.commons.vfs2.provider.tar.TarFileSystem.createTarFileObject
(org.apache.commons.vfs2.provider.AbstractFileName,
org.apache.commons.compress.archivers.tar.TarArchiveEntry)
org.apache.commons.vfs2.provider.tar.TarFileSystem.init ()
org.apache.commons.vfs2.provider.AbstractVfsContainer.addComponent (Object)
org.apache.commons.vfs2.provider.AbstractFileProvider.addFileSystem
(Comparable, org.apache.commons.vfs2.FileSystem)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem
(String, org.apache.commons.vfs2.FileObject,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String,
org.apache.commons.vfs2.FileSystemOptions)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile
(org.apache.commons.vfs2.FileObject, String)
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile (String)
I have tried to explicitly close the TarFileSystems after the processing is
done by calling
`VFS.getManager().closeFileSystem(archiveFileObject.getFileSystem())` but I see
no difference in the amount of live persistent objects.
I have also tried calling `((DefaultFileSystemManager)
VFS.getManager()).freeUnusedResources()` but no difference there either.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
