Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#13,858 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
java
領域
backend

調査の方向性

まず、ConsoleProxyVncClient、ConsoleProxyRdpClient、ConsoleProxyNoVncClient の ConsoleProxy.VIEWER_LINGER_SECONDS、ConsoleProxy.sessionTimeoutMillis、isFrontEndAlive() を読みます。consoleproxy.session.timeout を 180000 ms より大きく設定して問題を再現し、その後、legacy VNC、RDP、AJAX、noVNC のセッションがすべて、別個の 180 秒のしきい値ではなく、設定されたアイドルタイムアウトを使用することを確認します。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Java
スター
3.1k
フォーク
1.4k
平均マージ
6日 20時間
マージ済み PR(30日)
27

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/cloudstack のほかの issue

apache/cloudstack の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。