commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "L (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
Date Thu, 24 Aug 2017 07:20:00 GMT

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

L edited comment on VFS-640 at 8/24/17 7:19 AM:
------------------------------------------------

Avoiding slow connection would be nice but unfortunately we do not have that luxury.

I have created a patch for our internal use, see attachment. Some notes:
# The patch is based on 2.1 release and not on trunk.
# I tried to keep the code style but I did not verify it.
# It is indeed a lock keyed by the same key as the FileSystem. Its lifetime is almost the
same as lifetime of the corresponding FileSystem: it is created before the FileSystem but
is normally destroyed together with the FileSystem in AbstractFileProvider.closeFileSystem()
# The lock is ref-counted to support scenarios when creating a FileSystem fails. In this case
the lock is destroyed when ref count goes to 0.
# All the lock management happens under in AbstractFileProvider synchronized (fileSystems),
no new synchronization objects are created.
# There is no deadlock. There are only two lock patterns: either "synchronized (fileSystems)"
or "synchronized (newLock), synchronized (fileSystems)"
# There is also a test (ParallelConnTest.java). The test has two methods, to test the sequential
behavior (the same key) and the parallel behavior (different keys).



was (Author: klv_m72):
Avoiding slow connection would be nice but unfortunately we do not have that luxury.

I have created a patch for our internal use, see attachment. Some notes:
# The patch is based on 2.1 release and not on trunk.
# I tried to keep the code style but I did not verify it.
# It is indeed a lock keyed by the same key as the FileSystem. Its lifetime is almost the
same as lifetime of the corresponding FileSystem: it is created before the FileSystem but
is normally destroyed together with the FileSystem in AbstractFileProvider.closeFileSystem()
# The lock is ref-counted to support scenarios when creating a FileSystem fails. In this case
the lock is destroyed when ref count goes to 0.
# All the lock management happens under in AbstractFileProvider synchronized (fileSystems),
no new synchronization objects are created.
# There is no deadlock. There are only two lock patterns: either "synchronized (fileSystems)"
or "synchronized (newLock), synchronized (fileSystems)"


> Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
> -----------------------------------------------------------------------
>
>                 Key: VFS-640
>                 URL: https://issues.apache.org/jira/browse/VFS-640
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0, 2.1
>            Reporter: L
>         Attachments: ParallelConnTest.java, patch_VFS640.diff
>
>
> Currently (rev. 1802455) this method looks like this:
> {code:java}
>     protected synchronized FileSystem getFileSystem(final FileName rootName, final FileSystemOptions
fileSystemOptions)
>         throws FileSystemException
>     {
>         FileSystem fs = findFileSystem(rootName, fileSystemOptions);
>         if (fs == null)
>         {
>             // Need to create the file system, and cache it
>             fs = doCreateFileSystem(rootName, fileSystemOptions);
>             addFileSystem(rootName, fs);
>         }
>         return fs;
>     }
> {code}
> Given that there is a single instance of a provider per scheme, a very slow server that
is being accessed first time will block *all* other threads trying to access some other resources
via the same provider.
> We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We do not
mind the thread trying to access this method taking that long, but because of that "synchronized"
we end up having multiple threads accessing unrelated servers for the same scheme blocked.
> PS. Actually, it is not only AbstractOriginatingFileProvider. The same "provider-scoped"
lock is present in AbstractLayeredFileProvider, TemporaryFileProvider, and UrlFileProvider



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message