[ https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139702#comment-16139702 ]
Bernd Eckenfels commented on VFS-640: ------------------------------------- @L can younger us what provider in your original case caused the delay, maybe we should fix that anyway and move the connect to doAttach > 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)