Hi! 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 resources. Ciao, Mario [1] http://www.mail-archive.com/dev@commons.apache.org/msg10387.html -----Ursprüngliche Nachricht----- Von: news [mailto:n...@ger.gmane.org] Im Auftrag von Jörg Schaible Gesendet: Donnerstag, 06. August 2009 11:07 An: dev@commons.apache.org 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 time. 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
