From issues-return-8067-apmail-commons-issues-archive=commons.apache.org@commons.apache.org Mon May 11 08:40:10 2009 Return-Path: Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: (qmail 86279 invoked from network); 11 May 2009 08:40:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 May 2009 08:40:10 -0000 Received: (qmail 12493 invoked by uid 500); 11 May 2009 08:40:09 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 12391 invoked by uid 500); 11 May 2009 08:40:09 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 12381 invoked by uid 99); 11 May 2009 08:40:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 May 2009 08:40:09 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 May 2009 08:40:06 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 919B6234C004 for ; Mon, 11 May 2009 01:39:45 -0700 (PDT) Message-ID: <1456266082.1242031185584.JavaMail.jira@brutus> Date: Mon, 11 May 2009 01:39:45 -0700 (PDT) From: "Marek Zawirski (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (VFS-253) AbstractFileObject: wrong synchronization of content-related code In-Reply-To: <895195014.1241702790582.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/VFS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707936#action_12707936 ] Marek Zawirski commented on VFS-253: ------------------------------------ For our use case, I would like to set up one FileSystemManager for potentially multi-threaded application or even multiple application not aware about each other. I would like them to be unaware of each other as much as possible and act with VFS FIleObject, that I provide them, in a way like they are given ordinary VFS FileObject like any other. Such behavior is possible for mentioned java.io.File that is immutable as you said. So if application receives File or path, it can safely open another stream if necessary. IMHO disallowing that for mutable FileObject (which would require using some synchronization inside FileObject) is some limitation. The reason for it being thread-safe is that I hope they could be more easily shared then. In present way, considering that FileSystems cache opened FileObjects at FileSystemManager cache, it is impossible to easily and safely access concurrently the same file using the same FileSystemManager -> you can get the same FileObject. I would have to use separate FileSystemManagers instead, which I consider as limitation, as it requires several "mountings" of the same file systems or reduces the transparency of VFS, at least in my use case. > AbstractFileObject: wrong synchronization of content-related code > ----------------------------------------------------------------- > > Key: VFS-253 > URL: https://issues.apache.org/jira/browse/VFS-253 > Project: Commons VFS > Issue Type: Bug > Affects Versions: 2.0 > Reporter: Marek Zawirski > > Creating content through {{AbstractFileObject#getContent()}} and {{DefaultFileContent}} itself seem to be synchronized, but closing the content by {{AbstractFileObject#close()}} and checking whether it is open, by {{AbstractFileObject#isContentOpen()}} are NOT synchronized. > Both these methods miss some lock-object. For {{close()}} it may result in severe race condition in case of {{FileObject}} shared across more than one thread. > BTW, thead-safeness of important VFS classes/interfaces like {{FileObject}} is not documented in javadoc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.