[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
----------------------------------
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection<PosixFilePermission> perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
was:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection<PosixFilePermission> perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the ```handleCommandExitStatus(cmd,
channel)``` is called before the In/Out channels are auto-closed by the
try-with-resources block, and thus the EOF is not sent to the remote prior to
handling the exit status. The current implementation always times out first and
then sends an EOF while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> ----------------------------------------------------------------------------------
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Ryan Livingston
> Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection<PosixFilePermission> perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the _handleCommandExitStatus(cmd,
> channel)_ is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> _DefaultScpClient::runUpload()_ which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async issues when
> processing some remaining inbound messages from the remote after the pipe is
> closed.
> This issue is persistent on remote SSH servers running with CentOS and MacOS.
> This example is being run on MacOS 13.3.1 with a remote SSH server that has
> no explicit SSH configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
