[
https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778455#comment-16778455
]
Goldstein Lyor commented on SSHD-901:
-------------------------------------
{quote}
Personally I don't see why you would need to configure anything on the server,
you just check the boolean wantReply and send a reply if requested.
{quote}
Agreed - I believe we are saying the same thing - I was just indicating that if
one changes the "keepalive*" request to something else, then it is the user's
responsibility to register a handler for it on the server side.
> 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)
