[ http://issues.apache.org/jira/browse/VFS-98?page=comments#action_12447180 ] 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... AbstractFileProvider: ------------------------------------------------------------------- - 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 freeUnusedResources() These did not help yet, so I also made these modifications: AbstractFileObject: ------------------------------------------------------------------- - commented out synchronization stuff from detach() AbstractFileSystem: ------------------------------------------------------------------- - 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: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
