[
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)
