Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#198 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@NassimBtk ci sta già lavorando.

Dal 7/10/2026.

  • #200 di @NassimBtk — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
Java
Stelle
13
Fork
4
Merge medio
7h 38m
PR unite (30g)
14

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MetricsHub/winrm-java

Tutte le issue di MetricsHub/winrm-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.