Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

consoleproxy.session.timeout is honoured for noVNC sessions but not legacy VNC/RDP/AJAX viewers

Open
#13,858 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
java
Domain
backend

Research direction

Start by reading ConsoleProxy.VIEWER_LINGER_SECONDS, ConsoleProxy.sessionTimeoutMillis, and isFrontEndAlive() in ConsoleProxyVncClient, ConsoleProxyRdpClient, and ConsoleProxyNoVncClient. Reproduce the issue with consoleproxy.session.timeout set above 180000 ms, then verify that legacy VNC, RDP, AJAX, and noVNC sessions all use the configured idle timeout rather than a separate 180-second threshold.

Written by the indexing model from the issue text.

Description

component:console-proxy
problem

consoleproxy.session.timeout is now honoured for noVNC console sessions (#12810, PR #13058), but VNC/RDP/AJAX-based console viewers still rely on a separate, hardcoded idle threshold: ConsoleProxy.VIEWER_LINGER_SECONDS (180 seconds), used by isFrontEndAlive() in ConsoleProxyVncClient, ConsoleProxyRdpClient, and ConsoleProxyNoVncClient.

This means the effective idle timeout for a console session now depends on which viewer/hypervisor path served it:

  • noVNC sessions: idle timeout follows the configured consoleproxy.session.timeout (both via ConsoleProxyGCThread and, since PR #13058, the WebSocket session's own idle timeout).
  • Legacy VNC/RDP/AJAX sessions: idle timeout is still fixed at 180 seconds regardless of the consoleproxy.session.timeout setting.

An admin who sets consoleproxy.session.timeout to, say, 30 minutes to keep long-idle sessions open will still see legacy VNC/RDP/AJAX sessions get dropped after 3 minutes — an inconsistency that's confusing and undocumented.

versions

ACS 4.20+ (any branch carrying the PR #13058 / equivalent noVNC timeout fix)

The steps to reproduce the bug
  1. Set the global setting consoleproxy.session.timeout to a value well above 180000 ms (e.g. 1800000 ms / 30 minutes).
  2. Open a console session that uses the legacy VNC/RDP/AJAX path (e.g. a hypervisor or console mode that doesn't route through noVNC).
  3. Leave the session idle.
  4. Observe the session is torn down after ~180 seconds, not after the configured consoleproxy.session.timeout.
  5. Compare against a noVNC console session under the same setting, which correctly honours the configured value.
What to do about it?

Derive VIEWER_LINGER_SECONDS from the same configured consoleproxy.session.timeout value (ConsoleProxy.sessionTimeoutMillis) instead of keeping it as an independent hardcoded constant, so all console viewer types (noVNC, VNC, RDP, AJAX) honour one single, consistently-configured idle timeout.

This was flagged during review of PR #13058 (https://github.com/apache/cloudstack/pull/13058#discussion_r3309508273) but deliberately left out of that PR's scope, since it's a noVNC-focused backport and touching isFrontEndAlive() for the legacy viewer types is a broader behavioural change that deserves its own review/testing pass.

Dominant language
Java
Stars
3.1k
Forks
1.4k
Avg merge
6d 20h
Merged PRs (30d)
27

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/cloudstack

All issues in apache/cloudstack

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.