[
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=415978&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-415978
]
ASF GitHub Bot logged work on SSHD-901:
---------------------------------------
Author: ASF GitHub Bot
Created on: 04/Apr/20 15:02
Start Date: 04/Apr/20 15:02
Worklog Time Spent: 10m
Work Description: lgoldstein commented on issue #95: SSHD-901 Provide
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609041673
>> to close any dangling client sessions from server due to network issues
Please bear in mind that this mechanism is a **client side** one - i.e., it
is used by the client in order to detect a non-responsive server sooner than
the regular TCP/IP timeout would. AFAIK there is no server side mechanism to
detect "dangling" client sessions. We do have an idle-timeout mechanism that
closes a session if there is no traffic for the specified amount of time
(current default=10 minutes). The purpose of the `keepalive@` mechanism
(besides early detection) is also to generate some traffic so that the client
does not time out if there is no traffic. By activating the `wantReply` option
(default=disabled) we try to ensure that the server does not time out due to no
traffic. Therefore, the `keepalive@` mechanism is not likely to detect
"dangling clients" on the server side.
See
https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic
on client heartbeat details, and the code for `SessionHelper#getIdleTimeout`
There is a way to do this on the server side but it is rather
**non-standard** (which we support) and it involves sending {{SSH_MSG_IGNORE}}
messages from the server to the client thus maintaining some traffic on the
session as well as detecting "dangling clients". See `setSessionHeartbeat` API
with a {{HeartbeatType}} of `IGNORE`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 415978)
Time Spent: 40m (was: 0.5h)
> 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
> Assignee: Lyor Goldstein
> Priority: Major
> Fix For: 2.3.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
