apache / apache/servicecomb-java-chassis

getWaitTime in SyncResponseExecutor doen't consider retry times

Ouverte
#3,273 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub
Langage dominant
Java
Étoiles
1.9k
Forks
814
Merge moyen
8 j 23 h
PR mergées (30 j)
1

Description

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.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

Commencez par inspecter getWaitTime dans SyncResponseExecutor et retracez la manière dont retryOnNext ainsi que les timeouts de request et d’invocation sont configurés et utilisés. Vérifiez le comportement pour deux retries avec un timeout de request de 30 secondes, et considérez le problème comme résolu lorsque l’invocation reste active pendant toute la fenêtre de retry et que les response handlers continuent de s’exécuter.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
java
Domaine
backend-api-design, distributed-systems
Type d'issue
Bug
Difficulté
3/5
Temps estimé
1-2 jours
Activité
À l'abandon
Clarté
Plutôt claire
Accessibilité débutants
35/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.