[
https://issues.apache.org/jira/browse/VFS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Björn Persson Mattsson closed VFS-633.
--------------------------------------
Resolution: Not A Problem
See previous comment. The problem turned out to be caused by something else.
> 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)
