commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juha-Matti Toppinen (JIRA)" <>
Subject [jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe
Date Wed, 01 Nov 2006 12:32:19 GMT
    [ ] 
Juha-Matti Toppinen commented on VFS-98:

Thank you for the quick response.

Creating a per-thread FileSystemManager is not very comfortable, because I have many, many
classes that are shared between threads, and they all have a private main FileObject it uses
to store information etc. They also are maintained using Multiton -like pattern, so that only
one shared instance is created per FileObject, using FileObject.toString() as object pool
key. Redesigning all these classes to use per-thread FileSystemManagers as well as per-thread
FileObjects would be quite a lot of work.

I checked out and built VFS from SVN (nightly builds directory was empty) to get the latest
version, and still had the same problem.

I attach both a thread dump (thanks for the helpful link) as well as a report generated by

I tried both with the default VFS.getManager() and creating a custom DefaultFileSystemManager
that uses SynchronizedFileObject decorator. Only difference was that with SynchronizedFileObject
decorator the deadlock situation occurred more quickly. 

> VFS causes deadlocks or is not thread-safe
> ------------------------------------------
>                 Key: VFS-98
>                 URL:
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: Nightly Builds
>         Environment: jdk1.5.0_07 / Linux
>            Reporter: Juha-Matti Toppinen
>         Assigned To: Mario Ivankovits
>         Attachments: vfs.dead.jstack.txt, vfs.dead.threaddump.synchronizedfileobject.txt,
> Newer versions of VFS seems to be unusable in multithreading environments, causing a
deadlock of some kind. This causes my Java  web server application to completely hang when
there is many concurrent connections. My application uses a single FileSystemManager instance,
and makes quite heavy use of VFS; opening many files from many threads simultaneously.
> I have tried, without success different workarounds based on some mailing list threads:
> - Using both NullReferenceFilesCache and the default SoftReferenceFilesCache. (SoftReferenceFilesCache
seemed to sometimes cause some additional thread-related exceptions under heavy load, but
propably unrelated to this issue)
> - Using the new SynchorizedFileObjectDecorator also did not help. On the contrary, it
seemed to trigger the deadlock more easily.
> The version I have problems with is a nightly build: commons-vfs-20060831
> The older version commons-vfs-20060115 works beautifully, but I would like to use newer
version because I want to be able to use FileObject.refresh() to reset the internal state
of files (specially, to get a fresh list of children).
> I hope the threading issues are going to be resolved in near future, and I am willing
to help in any way. I do not have very deep experience about multithreading applications,
so I wasn't able to get more close to the roots of the issue. Feel free to ask for more information.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


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

View raw message