consoleproxy.session.timeout is honoured for noVNC sessions but not legacy VNC/RDP/AJAX viewers
- 主要言語
- Java
- スター
- 3.1k
- フォーク
- 1.4k
- 平均マージ
- 6日 19時間
- マージ済み PR(30日)
- 32
説明
### 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.
コントリビューションガイド
調査の方向性
まず、ConsoleProxyVncClient、ConsoleProxyRdpClient、ConsoleProxyNoVncClient の ConsoleProxy.VIEWER_LINGER_SECONDS、ConsoleProxy.sessionTimeoutMillis、isFrontEndAlive() を読みます。consoleproxy.session.timeout を 180000 ms より大きく設定して問題を再現し、その後、legacy VNC、RDP、AJAX、noVNC のセッションがすべて、別個の 180 秒のしきい値ではなく、設定されたアイドルタイムアウトを使用することを確認します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 静か
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 68/100