[jira] [Closed] (VFS-633) Memory/reference leak when handling tar.gz-files

["Björn Persson Mattsson (JIRA)" <ji...@apache.org>]

     [ 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)