commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Labrot (JIRA)" <>
Subject [jira] [Commented] (VFS-352) ZipFileSystem makes improper assumptions about FileCache
Date Thu, 30 Jul 2015 07:04:04 GMT


Nicolas Labrot commented on VFS-352:

The cache is implemented by an HashMap
Map<FileName, FileObject> cache = new HashMap<FileName, FileObject>();

{{ZipFileSystem#removeFileFromCache}} seems to never been called. When do entries get invalidated?
Is there a risk of OOM?

> ZipFileSystem makes improper assumptions about FileCache
> --------------------------------------------------------
>                 Key: VFS-352
>                 URL:
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Java 1.6
>            Reporter: Alex Bertram
>              Labels: cache, zip
>             Fix For: 2.1
>   Original Estimate: 24h
>  Remaining Estimate: 24h
> Upon init(), ZipFileSystem enumerates all the zip file entries and stores them in the
global FilesCache as well as a "strongRef" array. 
> The ZipFileSystem implementation assumes that this will be sufficient to keep all entries
in the cache, and so if the cache misses in AbstractFileSystem, ZipFileSystem assumes that
the file does not exist and returns an imaginary file.
> This implementation assumes that the WeakRefFilesCache is being used. If NullFilesCache
or LRUFilesCaches is used, these assumptions will fail and ZipFileSystem will fail to resolve
valid existing files within the system.
> ZipFileSystem should maintain its own internal cache instead.

This message was sent by Atlassian JIRA

View raw message