[
https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778422#comment-16778422
]
Goldstein Lyor commented on SSHD-901:
-------------------------------------
{quote}
I'm not proposing that the server sends a keep alive global request, I'm simply
proposing that it responds to one initiated by the client. But yes I am using
the Mina SSHD server too.
{quote}
This only re-enforces what I said - if the server on the other side is not MINA
SSHD, this mechanism might fail
{quote}
I just looked into the OpenSSH client and it sends its [email protected]
request with want reply true.1
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().
{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}
I'm not proposing that the server sends a keep alive global request, I'm simply
proposing that it responds to one initiated by the client
{quote}
We can do that, but how would we recognized the global request ? In your test
code you are using {{CloudConnectClient.KEEP_ALIVE}} whose value I don't see.
Please note that the SSHD client sends a global request configured via
{{"heartbeat-request"}} property whose default value is
{{"[email protected]"}}, 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).
> 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)
