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 Sat, 04 Nov 2006 20:04:19 GMT
    [ ] 
Juha-Matti Toppinen commented on VFS-98:

Hi again.

I had some progress on this issue. The problem seems to occur only when a single FileObject
is accessed from multiple threads. It works happily when using a single FileSystem, but accessing
different files in it simultaneously.

For me the possible one-time errors caused by the lack of proper synchronization do not matter
so much. But a deadlock on the FileSystem is really bad, causing may server to completely
stop responding. So I played around trying to fix the problem by just commenting out syncronization
stuff based on threaddump information. Not a the most professional method of working around
a bug, but I desperately needed a workaround ;)

Eventually I got it working, and I'll just list the not-so-well-thought modifications I made,
so you can maybe take a look at them and possibly use them as a basis for a proper fix...

- replaced  private final Map fileSystems = new TreeMap(); with: private final Map fileSystems
= java.util.Collections.synchronizedMap(new TreeMap()); in order to keep some thread-safety.
- commented out synchronization stuff from close(), addFileSystem(), findFileSystem() and

These did not help yet, so I also made these modifications:

- commented out synchronization stuff from detach()

- removed synchronized keywords from resolveFile(final FileName name) and resolveFile(final
FileName name, final boolean useCache)

And no deadlocks anymore. Hope this helps!

> 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