You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Björn Kautler (Jira)" <ji...@apache.org> on 2020/12/23 16:11:00 UTC

[jira] [Created] (SSHD-1113) Please protect from shooting your own foot

Björn Kautler created SSHD-1113:
-----------------------------------

             Summary: Please protect from shooting your own foot
                 Key: SSHD-1113
                 URL: https://issues.apache.org/jira/browse/SSHD-1113
             Project: MINA SSHD
          Issue Type: Improvement
    Affects Versions: 2.5.1
            Reporter: Björn Kautler


One of the cases I use MINA SSHD for is to "tail" a remote log file locally.
 This log file sometimes does not see an update for more than 10 minutes.
 This means the {{IDLE_TIMEOUT}} kicked in and closed the session.
 So I've set the {{IDLE_TIMEOUT}} to {{-1}} to have it disabled.
 Unfortunately that only gave me 15 more seconds until then the {{NIO2_READ_TIMEOUT}} kicked in.
 So I tried to also disable this one on the session which did not work at all.
 Through debugging I found out that this timeout is only read from the non-simple client and not from the session.
 So I switched to the non-simple client and set it there which worked.

So much for the context.
 It would already be nice if there were some protection that tells you that you set a property that will not have any effect where you set it, but I guess that will not work / be done.

Actually after I indeed got it working, I read that it is better to prevent those timeouts by activating heartbeat sending and that it is as easy as calling {{session.setSessionHeartbeat(IGNORE, MINUTES, 1)}} on the session.

I thought great, even easier, switched back to the simple client and called that method on the session. Unfortunately it did not work at all.
So again by debugging I found out, that is must be set on the session before the auth is done as it is only evaluated at that time once.

So I again switched back to the non-simple client and set the heartbeat before doing the {{auth}} call. This worked perfectly fine and now the connection stays open, even if the log file sees no update in a long time like needed.

It would be nice if there were some self-shooting protections, like an error if you try to call {{setSessionHeartbeat}} too late, or maybe the method not being available or usable when using the simple client, or maybe it should even work, adding a heartbeat even if the session was started already instead of only starting the heartbeating on session auth.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org