[ 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