[jira] [Commented] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

["Goldstein Lyor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777608#comment-16777608 ] 

Goldstein Lyor commented on SSHD-901:
-------------------------------------

Whether the server replies or not seems irrelevant to the scenario you describe. There are *distinct* pipelines - one for incoming packets and another for outgoing. Any exchange of messages between client and server occurs *asynchronously* - in this case, the client sends the {{keep-alive}} packet and then forgets all about it. It does not wait for a reply from the server. Even if the client would have liked to wait, the reply would arrive via the incoming packets pipeline via a *different thread* and (currently) there is no mechanism to synchronize the 2 pipelines (nor do I think it would be wise to have such a dangerous lock). The {{NIO2_READ_TIMEOUT}} expires if there is no traffic from the either peer - in this case, the client's timeout expires because there is *no traffic* whatsoever from the server. The scenario described in this issue seems to be a manifestation of SSHD-782.

The reason we do not implement SSHD-782 is that there does not seem to be any standard (de-facto or de-jure) for such a mechanism, and implementing it in some proprietary manner might disrupt existing clients that might not know how to handle it. We could consider adding such a mechanism as an *optional* one with a (big) *caveat emptor* (see further below).

Please note that such a mechanism would help only if the server is also MINA SSHD (due to its proprietary nature). However, if your client connects to some "generic" server (e.g., {{OpenSSH}}) - it might not have such a mechanism and then you would be back at square one. What I can suggest at this stage is to try and understand why your client is connecting to a server and then no traffic passes between them. It begs the question "why connect to a server if you are not going to do anything ?" - SCP, SFTP, shell, command - *anything*.

> InterruptedByTimeoutException occurring in client despite keepalive global request being sent
> ---------------------------------------------------------------------------------------------
>
>                 Key: SSHD-901
>                 URL: https://issues.apache.org/jira/browse/SSHD-901
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>         Environment: Windows 10
>            Reporter: Jared Wiltshire
>            Priority: Major
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a java.nio.channels.InterruptedByTimeoutException exception was being thrown by the client. After a little digging I discovered that this is the default value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83) - Session exception, session ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
> 	at sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614) ~[?:1.8.0_144]
> 	at sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649) ~[?:1.8.0_144]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_144]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_144]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_144]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_144]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_144]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_144]
> 	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) property set to less than 10 minutes and I verified that the global request is indeed being sent and received by the server.
> However I think that the issue is that the global request is sent with wantReply set to false. So the server does not reply with anything and the client does not read any data from the socket and hence times out.
> Does it not make sense for the server to reply? I believe this is a self defined global request (not in the SSH RFC) so we should be able change its behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)