You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@commons.apache.org by "BenD (JIRA)" <ji...@apache.org> on 2012/11/15 22:29:12 UTC

[jira] [Updated] (VFS-446) Undesired blocking during FileUtil.copyContent if destFile is SftpFileObject and the network connection to destFile goes away

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

BenD updated VFS-446:
---------------------

    Environment: 
Ubuntu 12.04 
jdk 1.6.0_34-b04
jsch-0.1.48

  was:
Ubuntu 12.04 
jdk 1.6.0_34-b04

    
> Undesired blocking during FileUtil.copyContent if destFile is SftpFileObject and the network connection to destFile goes away
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: VFS-446
>                 URL: https://issues.apache.org/jira/browse/VFS-446
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0
>         Environment: Ubuntu 12.04 
> jdk 1.6.0_34-b04
> jsch-0.1.48
>            Reporter: BenD
>
> I'm attempting to copy content of srcFile to destFile using FileUtil.copyContent(FileObject srcFile, FileObject destFile).  While the content is being transferred, but before it completes, I bring the network down on the destination sftp server.  No exception is thrown and thread blocks until what I can only assume is some long system timeout.  
> MonitorOutputStream appears to handle a client-side close fine but if the remote server closes the connection after the write already started then when the underlying BufferedOutputStream flushes to the underlying network stream it hangs until the system timeout expires.
> The subsequent destFile.getContent().getOutputStream().close() suffers the same fate as does the closing of destFile's FileSystemManager - I'm guessing because each attempts to flush to the underlying network stream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira