[
https://issues.apache.org/jira/browse/GUACAMOLE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David S. Jones updated GUACAMOLE-2233:
--------------------------------------
Description:
I had reported this in GUACAMOLE-2118 but it wasn't really the issue there..
Our implementation is pretty custom, we use our own web server and client
wrapper. We found that occasionally the session would be closed with the
message back to the browser
!image-2026-02-25-18-05-19-413.png!
and the same "User is not responding." in the log
We found that FireFox reliably sends the 5sec nop/keepalive message but Chrome
and Edge, when minimized or mostly occluded, would drop back to 37sec for
Chrome and 60sec for Edge and the 15sec timeout would expire.
It appears that the 1.5.3 guacd (that we are upgrading from) did NOT enforced
that timeout!
We experimented some with generating a "nop" message from our intermediary but
found we would need a 'sanity check escape', and because of our potentially
complex connectivity, we decided we'd just increase the timeout in quacd. We
tried 60sec but found that 'too on the edge for Edge' and bumped it to 65sec
which appears to be working very well (Sessions live for many days)
fix:
#define GUACD_TIMEOUT 65000
was:
I had reported this in GUACAMOLE-2118 but it wasn't really the issue there..
Our implementation is pretty custom, we use our own web server and client
wrapper. We found that occasionally the session would be closed with the
message back to the browser
!image-2025-09-08-15-11-59-435.png!
and the same "User is not responding." in the log
We found that FireFox reliably sends the 5sec nop/keepalive message but Chrome
and Edge, when minimized or mostly occluded, would drop back to 37sec for
Chrome and 60sec for Edge and the 15sec timeout would expire.
It appears that the 1.5.3 guacd (that we are upgrading from) did NOT enforced
that timeout!
We experimented some with generating a "nop" message from our intermediary but
found we would need a 'sanity check escape', and because of our potentially
complex connectivity, we decided we'd just increase the timeout in quacd. We
tried 60sec but found that 'too on the edge for Edge' and bumped it to 65sec
which appears to be working very well (Sessions live for many days)
fix:
#define GUACD_TIMEOUT 65000
> Chrome and Edge browsers can fail to report in a timely manner
> --------------------------------------------------------------
>
> Key: GUACAMOLE-2233
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2233
> Project: Guacamole
> Issue Type: Bug
> Components: guacd
> Affects Versions: 1.6.0
> Reporter: David S. Jones
> Priority: Minor
> Attachments: image-2026-02-25-18-05-19-413.png
>
>
> I had reported this in GUACAMOLE-2118 but it wasn't really the issue there..
> Our implementation is pretty custom, we use our own web server and client
> wrapper. We found that occasionally the session would be closed with the
> message back to the browser
> !image-2026-02-25-18-05-19-413.png!
> and the same "User is not responding." in the log
> We found that FireFox reliably sends the 5sec nop/keepalive message but
> Chrome and Edge, when minimized or mostly occluded, would drop back to 37sec
> for Chrome and 60sec for Edge and the 15sec timeout would expire.
> It appears that the 1.5.3 guacd (that we are upgrading from) did NOT enforced
> that timeout!
> We experimented some with generating a "nop" message from our intermediary
> but found we would need a 'sanity check escape', and because of our
> potentially complex connectivity, we decided we'd just increase the timeout
> in quacd. We tried 60sec but found that 'too on the edge for Edge' and bumped
> it to 65sec which appears to be working very well (Sessions live for many
> days)
> fix:
> #define GUACD_TIMEOUT 65000
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
