[
https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778433#comment-16778433
]
Jared Wiltshire commented on SSHD-901:
--------------------------------------
{quote} This only re-enforces what I said - if the server on the other side is
not MINA SSHD, this mechanism might fail
{quote}
How so? Any compliant SSH server should respond with either
SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE, whatever the result we
don't really care on the client end. We just want some sort of reply. As I
posted above the OpenSSH client sends its keep alive global request with "want
reply" true, there shouldn't be any compatibility issues.
{quote}Acceptable, but in order to avoid backward compatibility issues the
default will be zero - i.e., no reply expected. This means that users will have
to activate this option explicitly while taking full responsibility for any
incompatible behavior.
{quote}
Yeah I think this is totally the right way to go.
{quote}We can do that, but how would we recognized the global request ?
{quote}
Same as what the KeepAliveHandler currently does, I'm not proposing we change
this.
{code:java}
if (request.startsWith("keepalive@")) {
{code}
{quote}In your test code you are using CloudConnectClient.KEEP_ALIVE whose
value I don't see.
{quote}
Was simply a custom string that differentiated it from the standard keep alive.
bq. In order for the server to correctly answer it it must know about it -
something which will be left to the user. I.e., the it is the user;s
responsibility to configure both client and server (as you have done in your
sample code).
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.
> 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)
