Community
Participate
Working Groups
Build Identifier: M20080911-1700 I'm using an instance of extended type of RemoteCommandShellOperation to send commands to my remote SSH host. At proper connections, the sendCommand(String) method properly results in invocation of handle handleCommandFinished(String) method. But when I disconnect the connection physically and reconnect, and send command with the RemoteCommandShellOperation instance, it does not invoke the handleCommandFinished(String) or handOutputChanged(String). Here no doubt with the proper reconnection(Checked in the debug mode). Note: In both the case, prior to sending command, I'm using the RemoteCommandShellOperation.run() to activate the remote command shell if the shell is not active. After seeing in debug mode, it seems that the after the disconnect and reconnect actions, the RemoteCommandShellOperation.sendCommand(String) works fine but the invocation of RemoteCommandShellOperation.handCommandFinished(String) or RemoteCommandShellOperation.handOutputChanged(String)is never done by the TerminalServiceShellOutputReader. Reproducible: Always Steps to Reproduce: 1.Have proper connections, use RemoteCommandShellOperation.sendCommand(String). This invokes RemoteCommandShellOperation.handCommandShell(String) properly. 2. Physically disconnect and reconnect the remote system. 3. Use RemoteCommandShellOperation.sendCommand(String). This doesn't invoke RemoteCommandShellOperation.handCommandFinished(String) or RemoteCommandShellOperation.handOutputChanged(String) properly. Note: In both the case, prior to sending command, use the RemoteCommandShellOperation.run() to activate the remote command shell if the shell is not active.
Created attachment 166770 [details] Infinite read action by TerminalServiceOutputReader. This image shows that in debug mode, after disconnect & reconnect action, and after calling the sendCommand(String), the TerminalServiceOutputReader stops infinitely at the read() method.
Here, after the connection disconnect and reconnect actions, if I don't use the same RemoteCommandShellOperation instance and use a new instance to send commands, there is no problem in receiving the invocation of handleCommandFinished() and handleOutputChanged() methods. But the same RemoteCommandShellOperation instance becomes unusable after the connection disconnect and reconnect actions.
As new RemoteCommandShellOperation instance becomes usable after reconnection, I set the Importance to Normal.
Changed summary, previous value was: " sendCommand(String) method in doesn't invoke handleCommandFinished(String) method in RemoteCommandShellOperation once the Remote Host is physically disconnected and reconnected " My first suspicion here is that physically disconnecting causes the SSH Channel to disconnect. So it's expected that you cannot send/read anything from this channel any more. It looks like your RemoteCommandShellOperation would either have to listen to connectionLost events, or would have to check isConnected() before trying to write / read the target. This theory would also explain why a *new* RemoteCommandShellOperation instance works (it forces a physical reconnect of the SSH channel). Can you confirm this rough analysis? Do you think you could come up with a patch that satisfies your needs? Or is this something that could be handled in your client code?
(In reply to comment #4) > Changed summary, previous value was: > " > sendCommand(String) method in doesn't invoke handleCommandFinished(String) > method in RemoteCommandShellOperation once the Remote Host is physically > disconnected and reconnected > " > > My first suspicion here is that physically disconnecting causes the SSH Channel > to disconnect. So it's expected that you cannot send/read anything from this > channel any more. > > It looks like your RemoteCommandShellOperation would either have to listen to > connectionLost events, or would have to check isConnected() before trying to > write / read the target. > > This theory would also explain why a *new* RemoteCommandShellOperation instance > works (it forces a physical reconnect of the SSH channel). > > Can you confirm this rough analysis? Do you think you could come up with a > patch that satisfies your needs? Or is this something that could be handled in > your client code? Hi, thanks.. You are right.. After reconnecting, I found that it doesn't ask for user credentials when I use the same RemoteCommandShellOperation instance; but asks while using a new RemoteCommandShellOperation instance. I myself created a wraper on RemoteCommandShellOperation having lifecycle to check connection while using sendCommand() and to create a new RemoteCommandShellOperation instance the if the connection is not active. But it will be useful to document that RemoteCommandShellOperation instance is not usable after disconnect/reconnect and to have a wraper to maintain the lifecycle. It will be nice to have that kind of lifecycle class in RSE library itself. Or it will be more nice if the existing RemoteCommandShellOperation instance made to be reused after reconnect. Thanks..
Since you seem to understand the situation well, and you're able to test this, can you consider contributing a patch?
Created attachment 166940 [details] The wrapper that is used to send and handle remote commands This makes use of MyRemoteCommandShellOperation instance to send commands and handle the lifcycle. This might be useful.
Created attachment 166941 [details] The MyRemoteCommandShellOperation which mangages remote commands. The MyRemoteCommandShellOperation which mangages remote commands. This waits for command execution and also performs necessary logging of the console output. This might be useful.
