commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [vfs] VFS.getManager and FileCache
Date Thu, 06 Aug 2009 15:36:06 GMT

Using weak ref as default seems not too bad. However, since the file objects have just their
parent cached it might lead to much more file system access then now as a parent might need
to refresh its children.

I tried to kick a discussion about caching at all already [1].

I still think going the mount/unmount way and leaving all the concurrency/threading issues
up to the application makes more sense.
Means, VFS is no longer thread safe by default and you have to deal with thread safety only
if you use the object returned from mount() in differente threads. 
Also, by unmounting (equals filesystem.close()) we can easily get rid of any used underlaying



-----Ursprüngliche Nachricht-----
Von: news [] Im Auftrag von Jörg Schaible
Gesendet: Donnerstag, 06. August 2009 11:07
Betreff: [vfs] VFS.getManager and FileCache

Hi gang,

the docs of VFS praise VFS.getManager() as simplest possibility to work with
VFS. However, this setup uses a SortRefFileCache as default implementation.
This caused our server app to fail, since it means that FileObject
instances are only garbage collected if the Java process runs out of
memory. However, if the instance refer some other limited resource (in our
case for SFTP socket connections to the SFTP server) they may never be
released. Our SFTP server simply runs out of available connections over

Therefore we should possibly reconsider the default choice and use the
WeakRefFileCache instead. Since the FileObject instances are often linked
anyway with their parent/children references, the weak references are
normally not freed while the client has one reference left.

IMHO this behaviour matches the "simplest" (and less error-prone) approach
using VFS.getManager() most. WDYT?

- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message