Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <26881201.1180884495984.JavaMail.jira@brutus>
Date: Sun, 3 Jun 2007 08:28:15 -0700 (PDT)
From: "Chris Beams (JIRA)" <jira@apache.org>
To: commons-dev@jakarta.apache.org
Subject: [jira] Commented: (VFS-98) VFS causes deadlocks or is not
 thread-safe
In-Reply-To: <14391099.1162306588131.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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