You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "zhaixiaoxiang (GitHub)" <gi...@apache.org> on 2019/03/11 11:06:06 UTC

[GitHub] [incubator-dubbo] zhaixiaoxiang commented on issue #3634: [Dubbo-619] Fix #619 and PR #2956 is not enough

@carryxyh 谢谢你的建议.

大家在看这个 PR 前建议先看下 PR #2956 , 那里分析了出现issue #619 的原因.

PR #2956 那样改在社区版里看上去是没有问题的, 但是在某些情况下会有问题:

比如我们公司在FailoverClusterInvoker.doInvoke()里加了全链路监控埋点的代码, 如下所示:

![image](https://user-images.githubusercontent.com/11908486/54118472-0daaea00-442e-11e9-9533-3517670d4814.png)

在finally块里, 我们会取详细的exception异常栈(如果有的话), 然后记录在链路日志中, 用的如下这段:
`info.setExceptionStr(ExceptionUtils.getStackTrace(result.getException()));`

在执行这段代码之前, result.getException()里的stackTrace是null, 这没有问题, 因为服务端本来就抛出了没有异常栈的NullPointerException, (如果这里不懂的话, 建议先看一下 #2956 , 那里有详细的分析).

但是执行完这段代码后, 见如下截图:
![image](https://user-images.githubusercontent.com/11908486/54118802-da1c8f80-442e-11e9-9d7c-6221d681b0e1.png)

stackTrace 就变成了错误的异常栈, 也就是 issue #619 中出现那个误导用户的异常栈, 之所以在PR #2956 后还是有这个问题, 是因为是先执行的上面那块代码, 然后再执行RpcResult.recreate(), 而PR #2956 是在recreate里做的修改, 其实应该是在DecodeableRpcResult 类的handleException()方法里做异常栈的判断和修改:
![image](https://user-images.githubusercontent.com/11908486/54119315-fd940a00-442f-11e9-9d55-a8786d91f279.png)

![image](https://user-images.githubusercontent.com/11908486/54119342-0d135300-4430-11e9-9fdc-220d784f88a3.png)

本 PR 的目的是优化 PR #2956 , 在decode时就实现异常栈的检测和修改, 而不是等到InvokerInvocationHandler.invoke()后, recreate()时再做检测, 否则如果用户做二次开发时, 在诸如FailoverClusterInvoker.doInvoke()里用类似ExceptionUtils.getStackTrace()方法就破坏了异常栈, 所以要在源头就做好检测和修改, 这样更好一点.


[ Full content available at: https://github.com/apache/incubator-dubbo/pull/3634 ]
This message was relayed via gitbox.apache.org for notifications@dubbo.apache.org