Apache Commons VFS Thread Sicherheit und Ressourcenmanagement

Question

Ich bin in der Verwendung von Apache Commons VFS für ein Projekt, das Dateien zwischen lokalen Server und Remote-Servern über FTP, SFTP und HTTPS übertragen müssen.

Die Standardanwendungsbeispiele sind die FileSystemManager aus einer statischen Methode bekommen

FileSystemManager fsManager = VFS.getManager(); 

Ist es sicher, die gleiche FileSystemManager über mehrere Threads zu benutzen?

Und eine zweite Frage bezieht sich auf richtig Ressourcen in einem finally-Block Freigabe: Ich finde die folgenden Methoden in der 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()

Aber es ist nicht cle Welche Ressourcen sollten in der Regel geschlossen werden?

Answer 1

Die Filemanager und Dateisystemobjekte sollen threadsicher sein, aber ich würde nicht darauf wetten, dass ich davon lebe. Einige interne Sperren (insbesondere Umbenennungen) hängen von der Instanz von FileObject ab. Daher sollten Sie keinen FileCache verwenden, der diese nicht speichert (d. H. Der Standardcache ist in Ordnung).

FileContent und Streams sollten nicht gleichzeitig verwendet werden (FileContent.close() beispielsweise wirkt nur auf Streams des aktuellen Threads).

Es gibt einige Ressourcenlecks in diesem Bereich (hoffentlich alle in 2.1-SNAPSHOT behoben).

Answer 2

Der VFS.getManager bietet einen einzelnen Manager dh. Einfacher Zugriff auf das Dateisystem, daher werde ich es nicht aus einer Multithread-Umgebung empfehlen. Sie können Ihren eigenen DefaultFileSystemManager erstellen und die Methode close verwenden, wenn Sie fertig sind.