Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#198 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@NassimBtk ya está trabajando en esto.

Desde el 7/10/2026.

  • #200 de @NassimBtk — fusionado

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
Java
Estrellas
13
Forks
4
Merge medio
11 h 58 min
PR fusionados (30 d)
20

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MetricsHub/winrm-java

Todos los issues de MetricsHub/winrm-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.