Q
[apache/dubbo]dubbo 启动警告 warn [DUBBO] Failed to start NettyClient 'xxx'connect to the server 'yyy' (check == false, ignore and retry later!)
0
Environment
- Dubbo version: 3.0.X 3.1.X
- Operating System version: xxx
- Java version: 1.8
- 参考另一篇issue 把check=false和dynamic=true设置了 还是不行
- 启动AB两个之后 关闭B 重启A会去检查B 导致报错
- xxx
org.apache.dubbo.remoting.RemotingException: client(url: dubbo://192.168.31.100:20881/com.ruoyi.system.api.RemoteUserService?anyhost=true&application=ruoyi-auth&background=false&cache=false&check=false&codec=dubbo&deprecated=false&dubbo=2.0.2&dubbo.endpoints=[{"port":20881,"protocol":"dubbo"}]&dubbo.metadata.revision=7aa6a74b2033555ff9f68bcaa0559883&dubbo.metadata.storage-type=remote&dynamic=true&generic=false&heartbeat=60000&interface=com.ruoyi.system.api.RemoteUserService&ispuserver=true&logger=slf4j&metadata-type=remote&methods=getUserInfoByPhonenumber,registerUserInfo,getUserInfoByOpenid,getUserInfo&pid=20324&qos.enable=false®ister-mode=instance®ister.ip=192.168.31.100&release=3.1.2&service-name-mapping=true&side=consumer&sticky=false&timeout=3000×tamp=1667960478267&unloadClusterRelated=false&validation=false) failed to connect to server /192.168.31.100:20881, error message is:Connection refused: no further information: /192.168.31.100:20881
A
回答
3
5
看了一下源码 如果等于check等于false直接就会报警告
2
9
设置了不检查 还疯狂连接报错 这设置意义何在呢
2
首先 创建NettyClient连接报error 然后因为设置了 check=false 再报一条warn 哭笑不得
8
通过修改 AbstractClient 源码 check=false 直接停止后续连接操作 所有报错都解决了 功能也都正常
9
这个报错是注册中心推送地址后地址不可达的报错（有可用地址，但是地址连接失败）。
这里的 check 的作用是避免注册中心直接剔除这个地址（如果注册中心链路上有报错会直接剔除），日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存，否则在调用出现不通或者报错的时候会给分析带来难度（是注册中心问题还是网络问题还是使用方式问题等等）。
从规范上来说，注册中心是不应该推送不可达地址的，根本应该解决的问题是应该保证下游服务都启动完毕。
2
这个报错是注册中心推送地址后地址不可达的报错（有可用地址，但是地址连接失败）。
这里的 check 的作用是避免注册中心直接剔除这个地址（如果注册中心链路上有报错会直接剔除），日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存，否则在调用出现不通或者报错的时候会给分析带来难度（是注册中心问题还是网络问题还是使用方式问题等等）。
从规范上来说，注册中心是不应该推送不可达地址的，根本应该解决的问题是应该保证下游服务都启动完毕。
那就涉及到另一个bug了 生产者停机之后 为啥消费者启动还是能收到这个 生产者难道不应该主动删掉这段么
0
这个报错是注册中心推送地址后地址不可达的报错（有可用地址，但是地址连接失败）。
这里的 check 的作用是避免注册中心直接剔除这个地址（如果注册中心链路上有报错会直接剔除），日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存，否则在调用出现不通或者报错的时候会给分析带来难度（是注册中心问题还是网络问题还是使用方式问题等等）。
从规范上来说，注册中心是不应该推送不可达地址的，根本应该解决的问题是应该保证下游服务都启动完毕。
异常下线是应该留日志 但是正常下线也还是会报这个 这是不是个bug
8
生产者停机之后 为啥消费者启动还是能收到这个
剩余多少机器，是最后一台还是还有剩余机器。这台下线的机器注册中心中是否已经摘除。
2
生产者停机之后 为啥消费者启动还是能收到这个
剩余多少机器，是最后一台还是还有剩余机器。这台下线的机器注册中心中是否已经摘除。
基本都是开发的时候报这个错误 生产者重启 就一台 nacos该服务已经下线 但是元数据还有并没有删除 metadataType: remote
6
元数据是不随着服务上线生命周期清理的，这个不影响订阅。
可以试下在有两台机器的时候下线一台吗，或者是注册中心 url 配置加上 enable-empty-protection=false
6
元数据是不随着服务上线生命周期清理的，这个不影响订阅。 可以试下在有两台机器的时候下线一台吗，或者是注册中心 url 配置加上 enable-empty-protection=false
下线其中一台并没有影响 先启动生产者B 然后停止B 启动消费者A 就会报这个错误了 启动过程中报错 加了这个参数也一样 还是报错
只要有一台生产者还活着 就不会报这个错误
7
只要有一台生产者还活着 就不会报这个错误
那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。
加了这个参数也一样 还是报错
参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false？
8
只要有一台生产者还活着 就不会报这个错误
那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。
加了这个参数也一样 还是报错
参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false？
是的 一模一样 没什么效果
6
只要有一台生产者还活着 就不会报这个错误
那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。
加了这个参数也一样 还是报错
参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false？
2
enable-empty-protection=false 配置到下面的 parameters 里面
registry:
address: nacos://xxx
group: DUBBO_GROUP
parameters:
namespace: xxx
enable-empty-protection: false
4
enable-empty-protection=false 配置到下面的 parameters 里面
registry:
address: nacos://xxx
group: DUBBO_GROUP
parameters:
namespace: xxx
enable-empty-protection: false
还是一样 测了好半天
3
5
5
2
这个是一个默认行为问题。
为了高可用设计考虑，消费端开启了推空地址包括（当注册中心推送过来空地址列表的时候，忽略这条通知，因为在生产环境中不允许出现）。
这个设计的逻辑是：如果注册中心推送了空地址过来，那么调用一定会报错，因为没有地址了。那么是选择接受这个通知报 ‘无地址’ 错误，还是忽略这个通知（可能是注册中心的异常的误通知）报 ‘使用老地址，但地址连接不上’。
