11｜配置加载顺序：为什么你设置的超时时间不生效？

何辉

你好，我是何辉。今天我们探索 Dubbo 框架的第十道特色风味，配置加载顺序。
如何升级项目工程 pom 文件中某些 dependency 元素的版本号，想必你是轻车熟路了，一般情况下升级的版本都是向下兼容的，基本没问题，但如果跨越大版本升级，还是得多关注多验证一下，今天要解决的问题就是版本升级后出现的。
我们有这样一个敏感信息系统群，部分系统拓扑图如下：
图中有提供方和消费方应用，都从 dubbo2 升级到了 dubbo3 版本，升级后放到测试环境验证了一圈都挺正常的，然而在发布日当晚，刚把系统发布到预发环境，就开始出现了一些消费方调用超时的现象，截取了一段异常日志：
Caused by: org.apache.dubbo.remoting.TimeoutException: Waiting server-side response timeout by scan timer. start time: 2022-11-24 21:36:57.228, end time: 2022-11-24 21:36:58.246, client elapsed: 2 ms, server elapsed: 1016 ms, timeout: 1000 ms, request: Request [id=3, version=2.0.2, twoway=true, event=false, broken=false, data=RpcInvocation [methodName=decrypt, parameterTypes=[class java.lang.String], arguments=[Geek], attachments={path=com.hmilyylimh.cloud.facade.crypto.CryptoFacade, remote.application=dubbo-11-loadcfg-consumer, interface=com.hmilyylimh.cloud.facade.crypto.CryptoFacade, version=0.0.0, timeout=1000}]], channel: /192.168.100.183:49527 -> /192.168.100.183:28110
  at org.apache.dubbo.remoting.exchange.support.DefaultFuture.doReceived(DefaultFuture.java:212)
  at org.apache.dubbo.remoting.exchange.support.DefaultFuture.received(DefaultFuture.java:176)
  at org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask.notifyTimeout(DefaultFuture.java:295)
  at org.apache.dubbo.remoting.exchange.support.DefaultFuture$TimeoutCheckTask.lambda$run$0(DefaultFuture.java:282)
  at org.apache.dubbo.common.threadpool.ThreadlessExecutor$RunnableWrapper.run(ThreadlessExecutor.java:184)
  at org.apache.dubbo.common.threadpool.ThreadlessExecutor.waitAndDrain(ThreadlessExecutor.java:103)
  at org.apache.dubbo.rpc.AsyncRpcResult.get(AsyncRpcResult.java:193)
  ... 29 more

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了Dubbo框架升级后出现的超时时间设置不生效的问题，并通过调试分析的方式逐步解决了这一问题。作者首先描述了系统升级到Dubbo3版本后，在预发环境出现消费方调用超时的现象，尽管提供方和消费方的代码中都明确设置了超时时间。通过调试过程中的堆栈分析，发现了DefaultFuture中的异常以及新版本的服务发现类可能导致超时时间无法正确赋值的可疑点。文章通过具体的代码分析和调试过程，帮助读者深入理解Dubbo框架的配置加载顺序和超时时间设置的细节，同时也展示了如何通过调试解决系统问题。这篇文章适合对Dubbo框架有一定了解并希望深入学习其配置加载顺序和超时时间设置的开发人员阅读。通过阅读本文，读者可以加深对Dubbo框架的理解，提高对系统配置和调优的能力。文章内容详实，通过调试分析解决了Dubbo框架升级后超时时间设置不生效的问题，对于开发人员具有实际指导意义。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Dubbo 源码剖析与实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(11)

最新
精选

javaxu
想问下如何结合nacos 动态修改超时时间呢？
作者回复: 你好，javaxu：找寻通过 NacosService 拉取数据的核心关键口子，然后研究一番是怎么读取 nacos 配置的，相信你一下就能找到突破口的。
2023-06-09归属地：上海


飞飞
老师，比如客户端，服务端都配置了 timeout 这个属性，那这个以哪个为准，能展开讲讲这类在客户端、服务端都配置了属性的覆盖规则吗？
作者回复: 你好，飞飞：服务端配置了我timeout 后，最后会被消费者订阅，这样对于消费者而言，就天然有了两套，一套啥消费者本身设置的，一套是提供方订阅回来的，把握消费方优先，颗粒度越小越优先原则就好啦～
2023-05-26归属地：北京


张三丰
老师，下边这句话对意思就是dubbo3.0只能识别注解上的配置？不识别api的配置？参考今天问题中的具体情况，因为升级了 Dubbo 版本，消费方自己没配置任何超时时间，提供方使用了 API 方式设置超时时间，但是消费方并不感知，反而消费方感知的是提供方 @DubboService 中配置的内容。
作者回复: 你好，张三丰：不是不识别 api 的配置，而是在新老版本兼容的情况下，其实在消费方是有 api 的 invoke 对象的，只是因为消费方的订阅策略，所以选择了注解上的配置。对于这种新老版本兼容的情况，一定要周全的将一些重要的配置，该默认的都显示的默认好，并且做好策略的精准对应，方能很好的进行过度。
2023-03-21归属地：北京


夏帆
想问一下作者，加入我希望在dubbo的扩展点filter里面去动态的修改当前请求服务的超时时间应该怎么做呢
作者回复: 你好，夏帆：可以参考下【org.apache.dubbo.common.URL#getMethodParameter(java.lang.String, java.lang.String, int)】这个方法，然后想办法替换其中对应属性的值。
2023-03-20归属地：广东


徐有鱼
为什么提供方Local File方式的配置能被消费方拿到，而提供方API方式设置的超时时间消费方并不感知？优先级不也是API方式大于Local File方式吗？
作者回复: 你好，徐有鱼：因为提供方要注册，假设当作一个很普通的提供方服务方，那么这个提供服务方有哪些参数设置的能力，是不是得告诉别人，这样别人才能根据参数因地制宜的做出相应的对策，所以这也就是为什么提供方的一些参数需要通过注册的方式向别人宣告提供方的能力限制范围。但是恰巧这个场景是因为有接口级消费、应用级消费，混在一起，造成了这样的现象。
2023-03-13归属地：浙江


杨老师
老师，消费方为什么感知不到提供方以 API 方式设置的超时时间，提供方将这些信息也写到注册中心了呀。希望老师帮忙解答下
作者回复: 你好，杨老师：我在文中有这样一段描述〖因为提供方走进了默认的注册服务策略，消费方那边又恰好采用的是智能决策策略，就变成使用新版本服务发现类进行远程调用了。〗对于消费方而言，提供方通过API形式、注解形式的数据其实都在消费方的invokers中，只不过消费方总是有使用订阅策略的，恰巧使用到了新版的策略。
2023-03-03归属地：北京


Geek_5a425f
如果双方都不配，那默认是使用消费方的默认超时时间1000ms，也就是case 中1S 超时。
作者回复: 你好，Geek_5a425f：你理解是对的，可以从 DefaultFuture 源码类的构造方法可以看出来的。
2023-02-10归属地：北京


Geek_5a425f
『都是遵循着“粒度越细，优先级越高”的方式来处理的。』【先取方法级别的参数，再取服务级别的参数，最后取实例级别的参数】老是，我理解应该实例级别的参数优先级最高，这个理解有问题吗？
作者回复: 你好，Geek_5a425f：所谓的粒度越细，比如一个类有N个方法，那么方法就比类的粒度越细。也可以理解为越精确的地方粒度就越细。
2023-02-10归属地：北京


阿昕
思考题，nacos的配置级别依次为：namespace->data group->data id，同一个namespace下的group+dataId不能重复；dubbo的配置从namspace、group两个维度进行拆分，在使用上更符合服务配置的预期
作者回复: 你好，阿昕：你理解的很到位，确实是的，同一个namespace下的group+dataId不能重复。
2023-01-28归属地：浙江


y
老师，消费方并不感知提供方以 API 方式设置的超时时间，这个是 dubbo 本身的限制么，对 dubbo 不是很熟悉。
作者回复: 你好，y：消费方能感知到提供方API设置的参数，主要是提供方将这些信息写到了注册中心，消费方一旦订阅提供方的接口，然后就能感知提供方在API设置的这些参数了。如果想再找找感觉认识一下的话，可以留意后续的“第 25 章节，注册扩展”。
2023-01-14归属地：广东



收起评论