[
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
