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
- 平均合并
- 7 小时 38 分钟
- 30 天内合并 PR
- 14
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
MetricsHub/winrm-java 的其他 Issue
-
bug documentation
难度 2/5 1-3 小时 新手友好度 88/100
MetricsHub/winrm-java#202 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 58/100
MetricsHub/winrm-java#201 ·
维护者通常 1 天内回复
-
bug
难度 3/5 1-2 天 新手友好度 78/100
MetricsHub/winrm-java#199 ·
维护者通常 1 天内回复
-
Long-lived `WinRMClient` keeps failing with WSManFault 2150859174 after a terminate Signal fails可能已有人在做 @NassimBtk 于 1 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 25/100
MetricsHub/winrm-java#196 · 4 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 30/100
MetricsHub/winrm-java#194 ·
维护者通常 1 天内回复
查看 MetricsHub/winrm-java 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
Netcracker/qubership-integration-platform#1046 ·
维护者通常 2 天内回复
-
`check_java_version()` fails when Java path contains spaces (Windows / Git Bash, `C:\Program Files`)未关闭
难度 2/5 1-3 小时 新手友好度 68/100
-
Fix Math.ceilDiv wrong result for exact positive divisions可能已有人在做 @pamod-madubashana 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
scala-native/scala-native#5094 ·
维护者通常 1 天内回复
-
[Bug] AI unread message badge counts a batch of new bubbles as one message可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
apache/rocketmq-dashboard#5784 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
PCL-Community/PCL-CE#3658 ·
维护者通常 1 天内回复