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

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

     [ https://issues.apache.org/jira/browse/SSHD-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lyor Goldstein resolved SSHD-1113.
----------------------------------
    Resolution: Won't Fix

> 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
>            Priority: Major
>
> 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