[
https://issues.apache.org/jira/browse/SSHD-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254189#comment-17254189
]
Lyor Goldstein commented on SSHD-1113:
--------------------------------------
I empathize with your frustration, however SSH itself and the code that manages
it are quite complex. There are many (many many) clients and servers out there
as well as a myriad of requirements by the various users. The kind of
protection you mention actually seems to interfere with some things that other
users are doing. Furthermore, there are almost infinite number of combinations
of properties and possible inter-dependencies between them - so adding these
protections would be counterproductive as it would make the code a whole lot
more complex than what it already is.
To summarize, I don't think we can come up with a good policy and
implementation for said protections and all that is left is indeed to employ a
trial and error until one tunes up the code to ones needs - and there are as
many needs as there are users. I can only offer one consolation - I am willing
to bet that while you were struggling with the code you did learn quite a bit
about it, and next time you need to do something similar it may be ever
slightly easier.
> 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-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
