dubbo Bug.pdf
100墨值下载
点赞再看，养成习惯，微信搜索【三太⼦敖丙】关注这个互联⽹苟且偷⽣的⼯具⼈。
本⽂ GitHub https://github.com/JavaFamily 已收录，有⼀线⼤⼚⾯试完整考点、资料以及我
的系列⽂章。
背景
某天运营反馈，点了⼀次保存，但是后台出现了3条数据，我当时就想，不应该啊，这代码我⼏万年没
动了，我当时就叫他先别操作了，保留⼀下现场，我去排查⼀下。
我看了下新增的代码，直接右键查看作者
没想到三歪做过改动，我就去问三歪，XX模块的新增代码你是不是动过？
他沉默了很久没说话，然后抓起桌⼦上⽤剩下来的纸擦了擦鬓⻆留下的汗⽔，咽了⼀下⼝⽔说，是的我
改过，我把之前dubbo的xml配置⽅式改成了注解的⽅式。
怎么了？现在出BUG了？
你呀你，下次这种改动跟我说⼀下，我估计是dubbo源码的bug吧，不要慌，让我去看看什么问题。
正⽂
其实dubbo配置的⽅式有很多种，⼤家⽤的最多的就是xml配置的⽅式，如果不需要重试次数，我们会
加上重试次数为0，因为他默认是有多次的。
或者使⽤注解的⽅式
其实我已经⼤概知道是什么原因了，但是为了证实⾃⼰的猜想，于是开启了接下来的debug之旅~~~
注：dubbo版本：2.6.2
<dubbo:reference id="testService"
interface="heiidea.trade.service.sdk.interfice.TestService" retries="0"/>
@Reference(retries =0)
⾸先是在采⽤@Reference注解条件下：
采⽤@Reference注解配置重试次数
⾸先是都找到了dubbo重试的代码位置（启动dubbo项⽬，到调⽤接⼝时，F5进⼊⽅法，会跳转到
InvokerInvocationHandler中的invoke⽅法中，继续跟踪进⼊MockClusterInvoker中的invoke⽅法，然后
进⼊AbstractClusterInvoker中的invoke⽅法中，这⾥主要是拿到配置的负载均衡策略，后⾯会到
FailoverClusterInvoker的doInvoke⽅法中）。
重点来了，这⾥会获取配置的retries值，可以看到上⾯配置的是0，但是取出来居然是null，如图：
所以会返回defaultValue，加上本身调⽤的那⼀次，计算之后就会为3，如图：
所以可以发现，采⽤@Reference注解的形式配置retries为0时，dubbo重试次数为2次（3中包含本身调
⽤的那次）。
后⾯是采⽤ dubbo:reference 标签的⽅式：
⽅式如上，在获取属性的时候，可以看到获得的值为0，和注解形式配置的⼀致，如图：
of 7
100墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论