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