[
https://issues.apache.org/jira/browse/SSHD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777608#comment-16777608
]
Goldstein Lyor commented on SSHD-901:
-------------------------------------
Whether the server replies or not seems irrelevant to the scenario you
describe. There are *distinct* pipelines - one for incoming packets and another
for outgoing. Any exchange of messages between client and server occurs
*asynchronously* - in this case, the client sends the {{keep-alive}} packet and
then forgets all about it. It does not wait for a reply from the server. Even
if the client would have liked to wait, the reply would arrive via the incoming
packets pipeline via a *different thread* and (currently) there is no mechanism
to synchronize the 2 pipelines (nor do I think it would be wise to have such a
dangerous lock). The {{NIO2_READ_TIMEOUT}} expires if there is no traffic from
the either peer - in this case, the client's timeout expires because there is
*no traffic* whatsoever from the server. The scenario described in this issue
seems to be a manifestation of SSHD-782.
The reason we do not implement SSHD-782 is that there does not seem to be any
standard (de-facto or de-jure) for such a mechanism, and implementing it in
some proprietary manner might disrupt existing clients that might not know how
to handle it. We could consider adding such a mechanism as an *optional* one
with a (big) *caveat emptor* (see further below).
Please note that such a mechanism would help only if the server is also MINA
SSHD (due to its proprietary nature). However, if your client connects to some
"generic" server (e.g., {{OpenSSH}}) - it might not have such a mechanism and
then you would be back at square one. What I can suggest at this stage is to
try and understand why your client is connecting to a server and then no
traffic passes between them. It begs the question "why connect to a server if
you are not going to do anything ?" - SCP, SFTP, shell, command - *anything*.
> 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)
