You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Björn Persson Mattsson (JIRA)" <ji...@apache.org> on 2017/04/18 08:17:41 UTC
[jira] [Created] (VFS-633) Memory/reference leak when handling
tar.gz-files
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)