commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Beams (JIRA)" <j...@apache.org>
Subject [jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe
Date Sun, 03 Jun 2007 15:28:15 GMT

    [ https://issues.apache.org/jira/browse/VFS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501017
] 

Chris Beams commented on VFS-98:
--------------------------------

Mario,

Any other thoughts on this topic?  As Larry mentioned, we do have a workaround in place, but
it creates a severe performance penalty.  We've synchronized all access to the VFS FileSystemManager,
so all actions are serialized.  We're in a large-volume multithreaded environment, so this
quick fix isn't going to hold up for long.

VFS is so valuable to us that, if neccessary, we may go down the road of implementing a proper
fix ourselves.  Not knowing the codebase, however, this could take quite a bit of guesswork
and time.  Any help you can provide would be most appreciated.

Thanks - Chris 

> VFS causes deadlocks or is not thread-safe
> ------------------------------------------
>
>                 Key: VFS-98
>                 URL: https://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
>            Assignee: Mario Ivankovits
>         Attachments: vfs.dead.jstack.txt, vfs.dead.threaddump.synchronizedfileobject.txt,
vfs.dead.threaddump.txt, vfs_deadlock.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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
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