apache / apache/servicecomb-java-chassis

getWaitTime in SyncResponseExecutor doen't consider retry times

Offen
#3,273 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Java
Sterne
1.9k
Forks
814
Ø Merge
8 T. 23 Std.
Gemergte PRs (30 T.)
1

Beschreibung

version:2.6.0
code:getWaitTime in SyncResponseExecutor
```
private long getWaitTime(Invocation invocation) {
if (invocation.getOperationMeta().getConfig().getMsRequestTimeout() <= 0) {
return invocation.getOperationMeta().getConfig().getMsInvocationTimeout();
}
if (invocation.getOperationMeta().getConfig().getMsInvocationTimeout() <= 0) {
return invocation.getOperationMeta().getConfig().getMsRequestTimeout();
}
return Math.min(invocation.getOperationMeta().getConfig().getMsRequestTimeout(),
invocation.getOperationMeta().getConfig().getMsInvocationTimeout());
}
```
issue:The method getWaitTime in SyncResponseExecutor doen't consider retry times. This result in client request will be finished before the request really timeout. For example,consumer c invokes method m of provider p.The request timeout is 30s,and retryOnNext is 2.The request timeout really is 90s,but getWaitTime will return 30s.So,client invocation will timeout before response return.Baddly,the cmd in SyncResponseExecutor will be null,because the invocation will finish in advance.This result in handlers will not be executed in response callBack.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Beginnen Sie mit der Untersuchung von getWaitTime in SyncResponseExecutor und verfolgen Sie, wie retryOnNext sowie die Request- und Invocation-Timeouts konfiguriert und verwendet werden. Überprüfen Sie das Verhalten bei zwei Retries mit einem 30-sekündigen Request-Timeout, und betrachten Sie das Problem als gelöst, wenn die Invocation während des gesamten Retry-Fensters aktiv bleibt und die Response-Handler weiterhin ausgeführt werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
java
Bereich
backend-api-design, distributed-systems
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.