[ https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16138447#comment-16138447 ]
Gary Gregory commented on VFS-640: ---------------------------------- What solution do you propose that would still provide thread safety? > 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 > > 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)