[jira] [Updated] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad

2017-08-24 Thread L (JIRA)

 [ 
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

L updated VFS-640:
--
Attachment: patch_VFS640.diff
ParallelConnTest.java

patch_VFS640.diff: the patch
ParallelConnTest.java: the test

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


[jira] [Updated] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad

2017-08-23 Thread L (JIRA)

 [ 
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

L updated VFS-640:
--
Description: 
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

  was:
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.

Actually, it is not only 


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


[jira] [Updated] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad

2017-08-23 Thread L (JIRA)

 [ 
https://issues.apache.org/jira/browse/VFS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

L updated VFS-640:
--
Description: 
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.

Actually, it is not only 

  was:
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.


> 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.
> Actually, it is not only 



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