Streaming reconnect runs under the previous leg's expired deadline (1 ms connect budget)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- backend, networking
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- 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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MetricsHub/winrm-java
-
bug documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
MetricsHub/winrm-java#202 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
MetricsHub/winrm-java#201 ·
I maintainer di solito rispondono entro 1 giorno
-
Streaming command fails with a spurious timeout when reconnecting after an idle pauseForse già presa @NassimBtk l’ha presa 1 giorno fa. Aperta
MetricsHub/winrm-java#198 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Long-lived `WinRMClient` keeps failing with WSManFault 2150859174 after a terminate Signal failsForse già presa @NassimBtk l’ha presa 1 giorno fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
MetricsHub/winrm-java#196 · 4 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
MetricsHub/winrm-java#194 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di MetricsHub/winrm-java
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Netcracker/qubership-integration-platform#1046 ·
I maintainer di solito rispondono entro 2 giorni
-
`check_java_version()` fails when Java path contains spaces (Windows / Git Bash, `C:\Program Files`)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Fix Math.ceilDiv wrong result for exact positive divisionsForse già presa @pamod-madubashana l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
scala-native/scala-native#5094 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug] AI unread message badge counts a batch of new bubbles as one messageForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
apache/rocketmq-dashboard#5784 ·
I maintainer di solito rispondono entro 3 giorni
-
[i18n] 安装实例完成后的成功提示未正确本地化Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
PCL-Community/PCL-CE#3658 ·
I maintainer di solito rispondono entro 1 giorno