apache / apache/servicecomb-java-chassis
调用三方时负载均衡失败导致业务代码获取contextMgr为空
- Dominant language
- Java
- Stars
- 1.9k
- Forks
- 814
- Avg merge
- 8d 23h
- Merged PRs (30d)
- 1
Description
版本:1.3.10
代码实现:业务为REST接口,非Reactive模式,业务调用三方接口为Reactive模式,调用三方结束后,通过CompletableFuture的get方法获取三方调用结果后返回。
问题场景:压测的过程中,因三方未扩容,压测一段时间后负载均衡失败,LoadBalancer.chooseServer返回null,导致了InvokerUtils的reactiveInvoke方法传给invocation.next的AsyncResponse被调用:
```
invocation.next(ar -> {
ContextUtils.setInvocationContext(invocation.getParentContext());
try {
invocation.getInvocationStageTrace().finishHandlersResponse();
invocation.onFinish(ar);
asyncResp.handle(ar);
} finally {
ContextUtils.removeInvocationContext();
}
});
```
以上的ContextUtils.removeInvocationContext()语句执行,导致ContextUtils中的contextMgr被清理,如下业务代码执行触发空指针异常:
ContextUtils.getInvocationContext().getLocalContext().put(CommonConstant.RETURN_CODE,0)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the failed LoadBalancer.chooseServer path through InvokerUtils.reactiveInvoke and the AsyncResponse callback shown in the issue. Inspect how ContextUtils manages the invocation context around invocation.next and compare it with the CompletableFuture.get caller. Done means the failed third-party call no longer leaves business code with a null contextMgr; add or run regression coverage for this failure path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100