commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Persson Mattsson (JIRA) <j...@apache.org>
Subject [jira] [Commented] (VFS-633) Memory/reference leak when handling tar.gz-files
Date Tue, 18 Apr 2017 13:24:41 GMT

    [ https://issues.apache.org/jira/browse/VFS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972653#comment-15972653
] 

Björn Persson Mattsson commented on VFS-633:
--------------------------------------------

After more troubleshooting it turned out that the problem was ultimately caused by readers
that were never closed. Closing those readers/inputstreams before going out of scope allowed
for the previously persistent TarFileObject and TarFileEntry objects to be cleaned up during
garbage collection.

Closing this issue.

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

Mime
View raw message