[
https://issues.apache.org/jira/browse/SSHD-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17197043#comment-17197043
]
min yun law edited comment on SSHD-1078 at 9/16/20, 3:30 PM:
-------------------------------------------------------------
{code:java}
I've just tried using a native scp client to copy /proc/meminfo and it results
in an empty file, so this looks like the normal behavior, even if not really
expected. I think that's because the file size of those special files is
always zero{code}
if this is what SCP really do, it is ok. but when using SFTP, we can get
content of such memory file.
was (Author: minlaw):
{code:java}
I've just tried using a native scp client to copy /proc/meminfo and it results
in an empty file, so this looks like the normal behavior, even if not really
expected. I think that's because the file size of those special files is
always zero{code}
if this is what SCP really do, it is ok. but when using SFTP, we cannot get
content of such memory file.
> SCP/SFTP failed for big file upload
> -----------------------------------
>
> Key: SSHD-1078
> URL: https://issues.apache.org/jira/browse/SSHD-1078
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.5.1
> Reporter: min yun law
> Priority: Major
>
> Trying to merge product from jsch to mina sshd that keep the same SSH
> architecture (lets call SessionPool) which for each remote node, there is
> only one session object and limited channels (<=8) for executing commands and
> file operations. The SessionPool manages the session/channels for nodes and
> make sure only 8 threads(ssh channels) per node that can be run concurrently.
> This architecture works for Jsch for many years, but when using mina sshd,
> this architecture wont work when with upload big file, we always see
> following exception:
> {code:java}
> java.io.EOFException: Channel is being closed
> at
> org.apache.sshd.common.channel.AbstractChannel$2.<init>(AbstractChannel.java:794)
> at
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:792)
> at
> org.apache.sshd.common.channel.ChannelAsyncOutputStream.doWriteIfPossible(ChannelAsyncOutputStream.java:168)
> at
> org.apache.sshd.common.channel.ChannelAsyncOutputStream.writePacket(ChannelAsyncOutputStream.java:70)
> at
> org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.client.subsystem.sftp.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.client.subsystem.sftp.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> {code}
> From SSH server log, we see follow error:
> {code:java}
> Aug 19 15:56:38 xxxx sftp-server[202217]: error: Unknown message 0
> Aug 19 15:56:38 xxxx sftp-server[202217]: error: msg_len 0 < consumed 1
> {code}
> other client side exceptions by mina sshd as:
> org.apache.sshd.common.channel.WindowClosedException: Already closed:
> Window[client/remote](ChannelExec[id=79, recipient=1]-ClientSessionImp
>
> ----
> After many tries, finally I found that for big file upload/download, I have
> to give its own SshClient/ClientSession objects and then there will no such
> channel closing exception during file upload.
> That means we cannot share the same SshClient and ClientSession object per
> remote node to execute commands and file operations, and there may has bug in
> ClientSession when handle channels in this situation.
> the reason that we like to share the same SshClient/ClientSession for the
> same remote node is to manage the session/channels and close them when no
> usage, also to reduce the cost to allocate those objects.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
