[
https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778249#comment-16778249
]
Jared Wiltshire commented on SSHD-901:
--------------------------------------
I just looked into the OpenSSH client and it sends its [email protected]
request [with want reply
true|https://github.com/openssh/openssh-portable/blob/bc5e1169d101d16e3a5962a928db2bc49a8ef5a3/clientloop.c#L493].
I also read into the MINA SSH client code a little and it seems like my
assumption that we could just send a global request and not wait for the reply
might be incorrect. The test code I posted above does indeed stop the exception
being thrown but it might result in another global request that is waiting for
a reply via AbstractSession.request() getting the wrong response.
Do you think adding a configuration property for the keep alive that specifies
how long to wait for a reply is an option? If the property is set to greater to
zero we set "want reply" true and wait for that period of time for a response
via AbstractSession.request().
> 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)
