Apache Commons VFS thread safety and resource management

Question

I'm looking into using Apache Commons VFS for a project that will need to transfer files between local server and remote servers via ftp, sftp and https.

The standard usage examples are getting the FileSystemManager from a static method

FileSystemManager fsManager = VFS.getManager();

Is it safe to use the same FileSystemManager across multiple threads?

And a second question is about properly releasing resources in a finally block: I find the following methods in the Javadoc API:

• http://commons.apache.org/proper/commons-vfs/apidocs/org/apache/commons/vfs2/FileObject.html#close()
• http://commons.apache.org/proper/commons-vfs/apidocs/org/apache/commons/vfs2/FileSystemManager.html#closeFileSystem(org.apache.commons.vfs2.FileSystem)
• http://commons.apache.org/proper/commons-vfs/apidocs/org/apache/commons/vfs2/FilesCache.html#close()
• http://commons.apache.org/proper/commons-vfs/apidocs/org/apache/commons/vfs2/impl/DefaultFileSystemManager.html#close()

But it's not clear to me which of these resources should typically be closed.

Answer 1

The filemanager and filesystem objects are supposed to be thread safe, however I would not bet my live on it. Some internal locking (especially around renames) depend on the instance of the FileObject, so you should not use a FileCache which does not keep those (i.e. the default cache is fine).

FileContent and streams should not be used concurrently (in fact FileContent.close() for example only acts on streams of the current thread).

There are some resource leaks in this area (hopefully all fixed in 2.1-SNAPSHOT).

Answer 2

The VFS.getManager provides a single manager ie. single access to the filesystem, so I wont recommend using it from multithreaded environment. You can create your own DefaultFileSystemManager and use the close method when you are done.