You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sam Halliday (JIRA)" <ji...@apache.org> on 2016/02/04 23:50:39 UTC

[jira] [Comment Edited] (VFS-594) cache holds onto ZipFiles, which leak file handlers

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

Sam Halliday edited comment on VFS-594 at 2/4/16 10:50 PM:
-----------------------------------------------------------

ok, turns out VFS2 is **not** closing zipFiles when removing them from the cache. this is my hack

{{{
    // WORKAROUND https://issues.apache.org/jira/browse/VFS-594
    def nuke(jar: FileObject) = {
      jar.close()

      val fs = jar.getFileSystem

      val field = classOf[ZipFileSystem].getDeclaredField("zipFile")
      field.setAccessible(true)
      val zip = field.get(fs)
      if (zip != null)
        zip.asInstanceOf[ZipFile].close()

      vfs.getFilesCache.clear(fs)
    }
}}}


was (Author: fommil):
ok, turns out VFS2 is **not** closing zipFiles when removing them from the cache. this is my hack

    // WORKAROUND https://issues.apache.org/jira/browse/VFS-594
    def nuke(jar: FileObject) = {
      jar.close()

      val fs = jar.getFileSystem

      val field = classOf[ZipFileSystem].getDeclaredField("zipFile")
      field.setAccessible(true)
      val zip = field.get(fs)
      if (zip != null)
        zip.asInstanceOf[ZipFile].close()

      vfs.getFilesCache.clear(fs)
    }


> cache holds onto ZipFiles, which leak file handlers
> ---------------------------------------------------
>
>                 Key: VFS-594
>                 URL: https://issues.apache.org/jira/browse/VFS-594
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Sam Halliday
>
> The wonderful Java implementation of ZipFile opens up the file on instance creation. That's exceptionally wasteful on Linux but downright buggy on Windows, because Windows will then obtain an exclusive lock on that file.
> In ENSIME, this has the wonderful side effect of making compilation silently fail, because the compiler can't write out to the jar file, because it's being held by the IDE process.
> The references are being kept alive by the VFS cache. I'm going to try to disable it, as well as attempt as much manual closing of ZipFiles as I possibly can.
> Tracking from https://github.com/ensime/ensime-server/issues/1276



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)