apache / apache/servicecomb-java-chassis

getWaitTime in SyncResponseExecutor doen't consider retry times

未关闭
#3,273 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Java
星标
1.9k
派生
814
平均合并
8 天 23 小时
30 天内合并 PR
1

描述

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.

贡献指南

这个仓库没有索引到贡献指南

调研方向

首先检查 SyncResponseExecutor 中的 getWaitTime,并跟踪 retryOnNext 以及 request 和 invocation 超时的配置和使用方式。验证在 request 超时为 30 秒、进行两次 retry 时的行为;当 invocation 在整个 retry 窗口内保持活动状态且 response handlers 仍然运行时,即可认为问题已解决。

由索引模型根据 Issue 内容生成。

评估

技术栈
java
领域
backend-api-design, distributed-systems
Issue 类型
缺陷
难度
3/5
预计耗时
1-2 天
活跃度
停滞
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。