[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
