commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BenD (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (VFS-446) Undesired blocking during FileUtil.copyContent if destFile is SftpFileObject and the network connection to destFile goes away
Date Thu, 15 Nov 2012 21:15:12 GMT

    [ https://issues.apache.org/jira/browse/VFS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498343#comment-13498343
] 

BenD commented on VFS-446:
--------------------------

To work around I ditched using FileUtil.copyContent and implemented my own loop where each
write to the output stream was executed using a Future and setting a reasonable timer.

What is needed is a way for the underlying jsch.Session to signal/notify the SftpFileObject
its connection has been closed.

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

Mime
View raw message