Streaming reconnect runs under the previous leg's expired deadline (1 ms connect budget)
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 78/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- java
- Domaine
- backend, networking
Piste de recherche
Start by reading HttpTransport.java around connect(), ensureConnected() and post(), then trace the reconnect path from WsmanClient.java. Add the regression scenario described in StreamingApiTest: a late Receive response followed by a dropped connection and reconnect. Done means the streaming operation completes without a spurious connect timeout, while poll-mode deadlines remain shared across a poll.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem
In streaming mode (failOnQuietTimeout, i.e. HttpTransport.inactivityTimeout()), the socket deadline is per request leg: post() re-arms deadlineEpochMillis at the start of every leg (HttpTransport.java#L350).
But a reconnect does not go through post(). When the connection is gone, WsmanClient.send() calls transport.connect() explicitly before the authentication exchange (WsmanClient.java#L1166), and ensureConnected() caps the TCP connect and the TLS handshake with boundedByDeadline(connectTimeoutMillis) (HttpTransport.java#L318). That cap uses the deadline left over from the previous leg. If that leg ran long (a Receive that waited most of the inactivity timeout before the server dropped the connection, or a round trip that timed out), the leftover deadline is nearly or fully expired, and boundedByDeadline() floors it to 1 ms. The reconnect then fails with a connect timeout that has nothing to do with the server: a spurious TimeoutException for the streaming caller, or a wasted retry when connectRetries is set.
Where it bites today
PR #197 hit it on its Delete-then-Create sequence (a retired shell's Delete timing out, then the Create's reconnect) and works around it by calling configureTimeouts() again between the two requests. That resets the deadline for that one spot only; every other reconnect inside a streaming operation (a Receive, a Send, a Signal following a dropped connection) still runs under the stale deadline.
Proposed fix
Arm the per-leg deadline in connect() the same way post() does, so a reconnect gets the whole inactivity timeout for itself:
void connect() throws IOException {
if (deadlinePerLeg) {
deadlineEpochMillis = Utils.getCurrentTimeMillis() + readTimeoutMillis;
}
ensureConnected();
}
The configureTimeouts() re-call added by #197 can then go.
Poll mode (pollTimeout()) is unaffected: there the deadline is deliberately shared by every leg of one poll.
Test
StreamingApiTest: a command whose Receive the fake server answers late (close to the inactivity timeout) and then drops the connection, followed by a request that must reconnect; before the fix the reconnect fails with a connect timeout, after it the operation completes.
- 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
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de MetricsHub/winrm-java
-
bug documentation
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
MetricsHub/winrm-java#202 ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 3/5 1-2 jours Accessibilité débutants 58/100
MetricsHub/winrm-java#201 ·
Les mainteneurs répondent en général sous 1 jour
-
Streaming command fails with a spurious timeout when reconnecting after an idle pausePeut-être pris @NassimBtk l’a pris aujourd’hui. Ouverte
MetricsHub/winrm-java#198 · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Long-lived `WinRMClient` keeps failing with WSManFault 2150859174 after a terminate Signal failsPeut-être pris @NassimBtk l’a pris aujourd’hui. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 25/100
MetricsHub/winrm-java#196 · 4 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
MetricsHub/winrm-java#194 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de MetricsHub/winrm-java
Issues similaires
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
waiting-for-triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
spring-cloud/spring-cloud-openfeign#1443 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 1-3 heures Accessibilité débutants 84/100
ADORSYS-GIS/keycloak-oid4vp-plugin#221 ·
Les mainteneurs répondent en général sous 2 jours
-
Upgrade to Spring Pulsar 2.0.8Ouvertestatus: team-only type: dependency-upgrade
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
spring-projects/spring-boot#52099 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
tchiotludo/akhq#3307 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour