[apache/dubbo]dubbo 启动警告 warn [DUBBO] Failed to start NettyClient 'xxx'connect to the server 'yyy' (check == false, ignore and retry later!)

2024-05-24 981 views
9
Environment
  • Dubbo version: 3.0.X 3.1.X
  • Operating System version: xxx
  • Java version: 1.8
  1. 参考另一篇issue 把check=false和dynamic=true设置了 还是不行
  2. 启动AB两个之后 关闭B 重启A会去检查B 导致报错
  3. 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&register-mode=instance&register.ip=192.168.31.100&release=3.1.2&service-name-mapping=true&side=consumer&sticky=false&timeout=3000&timestamp=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

回答

4

image

0

看了一下源码 如果等于check等于false直接就会报警告 image

4

感觉这块设计的非常有问题

7

设置了不检查 还疯狂连接报错 这设置意义何在呢 image

9

首先 创建NettyClient连接报error 然后因为设置了 check=false 再报一条warn 哭笑不得

3

image 通过修改 AbstractClient 源码 check=false 直接停止后续连接操作 所有报错都解决了 功能也都正常

4

这个报错是注册中心推送地址后地址不可达的报错(有可用地址,但是地址连接失败)。

这里的 check 的作用是避免注册中心直接剔除这个地址(如果注册中心链路上有报错会直接剔除),日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存,否则在调用出现不通或者报错的时候会给分析带来难度(是注册中心问题还是网络问题还是使用方式问题等等)。

从规范上来说,注册中心是不应该推送不可达地址的,根本应该解决的问题是应该保证下游服务都启动完毕。

1

这个报错是注册中心推送地址后地址不可达的报错(有可用地址,但是地址连接失败)。

这里的 check 的作用是避免注册中心直接剔除这个地址(如果注册中心链路上有报错会直接剔除),日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存,否则在调用出现不通或者报错的时候会给分析带来难度(是注册中心问题还是网络问题还是使用方式问题等等)。

从规范上来说,注册中心是不应该推送不可达地址的,根本应该解决的问题是应该保证下游服务都启动完毕。

那就涉及到另一个bug了 生产者停机之后 为啥消费者启动还是能收到这个 生产者难道不应该主动删掉这段么

4

这个报错是注册中心推送地址后地址不可达的报错(有可用地址,但是地址连接失败)。

这里的 check 的作用是避免注册中心直接剔除这个地址(如果注册中心链路上有报错会直接剔除),日志中的报错在生产定位原因的时候是必要的。即使是没有通过地址剔除这种严格的处理也不应该任何日志不留存,否则在调用出现不通或者报错的时候会给分析带来难度(是注册中心问题还是网络问题还是使用方式问题等等)。

从规范上来说,注册中心是不应该推送不可达地址的,根本应该解决的问题是应该保证下游服务都启动完毕。

异常下线是应该留日志 但是正常下线也还是会报这个 这是不是个bug

2

生产者停机之后 为啥消费者启动还是能收到这个

剩余多少机器,是最后一台还是还有剩余机器。这台下线的机器注册中心中是否已经摘除。

8

生产者停机之后 为啥消费者启动还是能收到这个

剩余多少机器,是最后一台还是还有剩余机器。这台下线的机器注册中心中是否已经摘除。

基本都是开发的时候报这个错误 生产者重启 就一台 nacos该服务已经下线 但是元数据还有并没有删除 metadataType: remote

9

元数据是不随着服务上线生命周期清理的,这个不影响订阅。 可以试下在有两台机器的时候下线一台吗,或者是注册中心 url 配置加上 enable-empty-protection=false

2

元数据是不随着服务上线生命周期清理的,这个不影响订阅。 可以试下在有两台机器的时候下线一台吗,或者是注册中心 url 配置加上 enable-empty-protection=false

下线其中一台并没有影响 先启动生产者B 然后停止B 启动消费者A 就会报这个错误了 启动过程中报错 加了这个参数也一样 还是报错 image

只要有一台生产者还活着 就不会报这个错误

2

只要有一台生产者还活着 就不会报这个错误

那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。

加了这个参数也一样 还是报错

参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false

1

只要有一台生产者还活着 就不会报这个错误

那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。

加了这个参数也一样 还是报错

参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false

是的 一模一样 没什么效果

5

只要有一台生产者还活着 就不会报这个错误

那就是推空保护导致的在无 provider 的时候会留下最后一台 provider 去尝试连接。

加了这个参数也一样 还是报错

参数是这样配置的 nacos://127.0.0.1:8848?enable-empty-protection=false

image

8

enable-empty-protection=false 配置到下面的 parameters 里面

registry:
  address: nacos://xxx
  group: DUBBO_GROUP
  parameters:
    namespace: xxx
    enable-empty-protection: false
3

enable-empty-protection=false 配置到下面的 parameters 里面

registry:
  address: nacos://xxx
  group: DUBBO_GROUP
  parameters:
    namespace: xxx
    enable-empty-protection: false

image image 还是一样 测了好半天

7

可以给一个复现方式嘛

9

这个是一个默认行为问题。

为了高可用设计考虑,消费端开启了推空地址包括(当注册中心推送过来空地址列表的时候,忽略这条通知,因为在生产环境中不允许出现)

这个设计的逻辑是:如果注册中心推送了空地址过来,那么调用一定会报错,因为没有地址了。那么是选择接受这个通知报 ‘无地址’ 错误,还是忽略这个通知(可能是注册中心的异常的误通知)报 ‘使用老地址,但地址连接不上’。