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

Streaming command fails with a spurious timeout when reconnecting after an idle pause

Closed
  • Is something wrong?
#198 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@NassimBtk is already working on this.

Since Oct 7, 2026.

  • #200 by @NassimBtk — merged

Assessment

This issue has not been assessed yet.

Description

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.

Dominant language
Java
Stars
13
Forks
4
Avg merge
12h 44m
Merged PRs (30d)
17

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 MetricsHub/winrm-java

All issues in MetricsHub/winrm-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.