commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juha-Matti Toppinen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe
Date Wed, 01 Nov 2006 12:32:19 GMT
    [ http://issues.apache.org/jira/browse/VFS-98?page=comments#action_12446226 ] 
            
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
jstack.

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: http://issues.apache.org/jira/browse/VFS-98
>             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,
vfs.dead.threaddump.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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message