apache / apache/servicecomb-java-chassis

调用三方时负载均衡失败导致业务代码获取contextMgr为空

オープン
#3,956 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
need discussion
主要言語
Java
スター
1.9k
フォーク
814
平均マージ
8日 23時間
マージ済み PR(30日)
1

説明

版本: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)

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

まず、issue に示されている AsyncResponse コールバックと InvokerUtils.reactiveInvoke を通る、失敗した LoadBalancer.chooseServer のパスを追跡します。ContextUtils が invocation.next の前後で呼び出しコンテキストをどのように管理しているかを調べ、CompletableFuture.get の呼び出し元と比較します。失敗したサードパーティ呼び出しによってビジネスコードに null contextMgr が残されなくなれば完了です。この失敗パスの回帰テストカバレッジを追加するか、実行します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
api, backend
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。