[
https://issues.apache.org/jira/browse/GUACAMOLE-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291081#comment-17291081
]
Edgardo Rodriguez commented on GUACAMOLE-1126:
----------------------------------------------
As a general rule, I think that having a piece of code which allows a infinite
loop is not a good practice. I agree that there might be a bug that
missinterpret a particular error code leading to these reconnect attempts and
that should be covered (bug-fix) elsewhere.
But having a "auto-reconnect handler" which has no limit at all does not sound
good IMHO. Every piece of code should have a beggining but also an ending.
Perhaps an interaction with user activity might be used, If user is away from
computer then don't try to infinitelly reconnect, just try to do so a few
times. Additionally, by handling user activity, auto-reconnect might be
automatically resumed whenever user came back.
> Implement Maximum auto-reconnect attempts
> -----------------------------------------
>
> Key: GUACAMOLE-1126
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1126
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-client
> Reporter: Edgardo Rodriguez
> Priority: Minor
>
> Using guacamole for 60+ users I've realized that sometimes, RDP hosts "go
> away" because of hardware issues, dns issues, etc and users might not be
> aware of it.
> For example, they leave their computer with the browser open with session
> established and going on... When this happens, Guacamole tries to
> auto-reconnect every 15 seconds without any limitation (some times
> indefinitely) and also, SESSION TIMER is renewed because of fake? user
> activity.
> I've implemented a counter which allows automatic reconnection attempts for
> up to 4 tries. When tried 4 times, countdown timer is not further applied and
> so user is left with manual Reconnect dialog prompt as usual.
> I `ve not implemented a visual indication like 1/4 2/4,etc because it
> involves transalations and other "more complex" stuff.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
