Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#198 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@NassimBtk y travaille déjà.

Depuis le 7/10/2026.

  • #200 par @NassimBtk — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

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.

Langage dominant
Java
Étoiles
13
Forks
4
Merge moyen
1 j 9 h
PR mergées (30 j)
15

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MetricsHub/winrm-java

Toutes les issues de MetricsHub/winrm-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.