Streaming reconnect runs under the previous leg's expired deadline (1 ms connect budget)
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 78/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- java
- Bereich
- backend, networking
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Java
- Sterne
- 13
- Forks
- 4
- Ø Merge
- 7 Std. 38 Min.
- Gemergte PRs (30 T.)
- 14
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus MetricsHub/winrm-java
-
bug documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
MetricsHub/winrm-java#202 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
MetricsHub/winrm-java#201 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Streaming command fails with a spurious timeout when reconnecting after an idle pauseEvtl. vergeben @NassimBtk hat das vor 1 Tag übernommen. Offen
MetricsHub/winrm-java#198 · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
-
Long-lived `WinRMClient` keeps failing with WSManFault 2150859174 after a terminate Signal failsEvtl. vergeben @NassimBtk hat das vor 1 Tag übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 25/100
MetricsHub/winrm-java#196 · 4 Kommentare · 1 zugewiesene Person ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
MetricsHub/winrm-java#194 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in MetricsHub/winrm-java
Ähnliche Issues
-
Fix Math.ceilDiv wrong result for exact positive divisionsEvtl. vergeben @pamod-madubashana hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
scala-native/scala-native#5094 ·
Maintainer antworten meist innerhalb von 1 Tag
-
[Bug] AI unread message badge counts a batch of new bubbles as one messageEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
apache/rocketmq-dashboard#5784 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
PCL-Community/PCL-CE#3658 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
apache/skywalking#14127 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag