Streaming command fails with a spurious timeout when reconnecting after an idle pause
メンテナーはふだん 1 日以内に返信
評価
この issue はまだ評価されていません。
説明
Disclaimer: Although the following content is generated by AI, I have thoroughly reviewed and cleaned it.
Problem
A streaming command (e.g. a RemoteProcess whose output is read slowly) can fail with a spurious timeout:
TimeoutException: No response from the WinRM service
even though the server is healthy and reachable. It happens when the consumer pauses between two reads for longer than both the inactivity timeout and the host's idle keep-alive timeout (HTTP.sys drops idle connections after 120 s by default).
Cause
In streaming mode (HttpTransport.inactivityTimeout(int)), every request leg gets its own absolute deadline: post() arms deadlineEpochMillis = now + readTimeoutMillis before sending, and every socket wait (connect, TLS handshake, reads) is capped by what is left of it, with a 1 ms floor.
But when the server dropped the connection, WsmanClient.send() reconnects explicitly with transport.connect() before calling post() (so that connection failures can be retried safely, see #158). connect() does not arm a new deadline: it reuses the one left by the previous leg. If that leg started more than one inactivity timeout ago, the deadline has already expired, so:
Socket.connect(..., boundedByDeadline(connectTimeoutMillis))gets 1 ms- the TLS handshake (
setSoTimeout(boundedByDeadline(readTimeoutMillis))+startHandshake()) gets 1 ms
Over a real network, or with HTTPS, this fails with a SocketTimeoutException, which the streaming paths report as a TimeoutException.
A fresh operation is not affected (configureTimeouts() resets the deadline at the start of each operation). Only a reconnection within a streaming operation is.
Fix
In HttpTransport.connect(), when the per-leg deadline mode is active, arm a fresh deadline before connecting, so the explicit reconnection is a leg of its own. The pollTimeout mode (one absolute deadline shared by all legs) and the blocking mode (no deadline) are unchanged.
- 主要言語
- Java
- スター
- 13
- フォーク
- 4
- 平均マージ
- 12時間 44分
- マージ済み PR（30日）
- 17
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
MetricsHub/winrm-java のほかの issue
-
bug documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
MetricsHub/winrm-java#202 ·
メンテナーはふだん 1 日以内に返信
-
WQL array properties: add the trailing separator to match wmi-java対応中かも @bertysentry が今日担当しました。 オープンenhancement
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
MetricsHub/winrm-java#201 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 78/100
MetricsHub/winrm-java#199 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
MetricsHub/winrm-java#194 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
MetricsHub/winrm-java#176 ·
メンテナーはふだん 1 日以内に返信
MetricsHub/winrm-java の issue をすべて見る
似ている issue
-
[Bug] The producer summary counts an unreported client version as a second version and warns about a version mix対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
apache/rocketmq-dashboard#6110 ·
メンテナーはふだん 4 日以内に返信
-
`Processing lsp` never exits and leaves orphaned processes対応中かも @overcast302 が今日担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
processing/processing4#1578 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/doris-flink-connector#707 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 60/100
メンテナーはふだん 1 日以内に返信
-
[BUG] S3 CORS responses omit Access-Control-Allow-Credentials for matched origins対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
floci-io/floci#5369 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信