[jira] [Comment Edited] (SSHD-671) Internal hang (timeout) using ScpClient.upload()

["Goldstein Lyor (JIRA)" <ji...@apache.org>]

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

Goldstein Lyor edited comment on SSHD-671 at 7/2/16 4:01 AM:
-------------------------------------------------------------

I know why you are getting a 5 sec. delay/hang - following SSHD-628, a timeout was introduced to allow some extra time for the channel exit status to reach the SCP client. Most servers seem to send such a status so there is no delay at the end of the upload/download. If a server does not send such a status or does not close the channel on time (as may be the case in your setup), then such a delay may occur. There is an immediate fix for this, but it comes with a possible cost - if you set the "channel-close-timeout" property (see {{FactoryManager#CHANNEL_CLOSE_TIMEOUT}}) to a lower value (NOT ZERO as it means "forever") you will experience a shorter delay. As said, though, it comes with a price - unfortunately, the same value is used when sending the CHANNEL_CLOSE command to check that the packet has been sent. If you set it too low, you migh start getting reports that the channel close wait has failed.

Another possible workaround might be to override the {{AbstractClientSession}} class and create a {{MyDefaultScpClient extends DefaultScpClient}} and override the {{handleCommandExitStatus(String cmd, ClientChannel channel)}} to call {{handleCommandExitStatus(String cmd, Integer exitStatus)}} with a _null_ exit status without waiting on a real status to arrive.

As a fix for this issue I will add a *separate* timeout value for SSHD-628 and allow non-positive values to indicate no-wait.


was (Author: lgoldstein):
I know why you are getting a 5 sec. delay/hang - following SSHD-628, a timeout was introduced to allow some extra time for the channel exit status to reach the SCP client. Most servers seem to send such a status so there is no delay at the end of the upload/download. If a server does not send such a status or does not close the channel on time (as may be the case in your setup), then such a delay may occur. There is an immediate fix for this, but it comes with a possible cost - if you set the "channel-close-timeout" property (see {{FactoryManager#CHANNEL_CLOSE_TIMEOUT}}) to a lower value (NOT ZERO as it means "forever") you will experience a shorter delay. As said, though, it comes with a price - unfortunately, the same value is used when sending the CHANNEL_CLOSE command to check that the packet has been sent. If you set it too low, you migh start getting reports that the channel close wait has failed.

Another possible workaround might be to override the {{AbstractClientSession}} class and create a {{MyDefaultScpClient extends DefaultScpClient}} and override the {{handleCommandExitStatus(String cmd, ClientChannel channel)}} to call {{handleCommandExitStatus(String cmd, Integer exitStatus)}} with a _null_ exit status without waiting on a real status to arrive.

As a fix for this issue I will add a *separate* timeout value for this feature and allow zero to indicate no-wait.

> Internal hang (timeout) using ScpClient.upload()
> ------------------------------------------------
>
>                 Key: SSHD-671
>                 URL: https://issues.apache.org/jira/browse/SSHD-671
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Oliver Stöneberg
>            Assignee: Goldstein Lyor
>         Attachments: scp_upload_hang.txt
>
>
> Uploading via SCP seems to be extremely slow compared to SFTP and simple command execution via SSH. It looking at the log it appears that after it uploaded the complete file it runs into a (5 second) timeout which makes the upload appear slow. See the attached log file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)