服务端启动新实例时，消费端调用不到，需要重启消费端

[caichy]

我试了半天，都没没有复现出来。
不过在本机尝试复现的时候，需要注意 dubbo 的协议端口注意分开，不然有可能冲突造成服务端数据有问题

@theonefx dubbo配置如下，服务端和消费端一样

registry:
address: spring-cloud://nacos.test.xxx.cn:8080
consumer:
timeout: 10000
check: true
protocol:
name: dubbo
port: -1

两个机器，IP为121和122，分别部署两个Provider，在122上部署Consumer，访问http://122:8800/dubbo/get/1 来测试dubbo接口是否可用，以下方便描述我用Provider-122，Provider-121，Consumer-122来代表实例

第一步，先启动Provider-122和Consumer-122实例，访问/dubbo/get/1正常。

第二步，再启动Provider-121，Provider-122和Consumer-122都会收到InstancesChangeEvent，nacos也注册成功

访问/dubbo/get/1正常，dubbo请求只会打到第一次启动的122（如果先启动两个Provider，load balance是正常的）

第三步，停止Provider-122，用的kill命令，Provider-121和Consumer-122都会收到InstancesChangeEvent，nacos取消注册成功

访问/dubbo/get/1报错，提示Tried 3 times of the providers [172.24.30.122:20881] (1/1)；
ReconnectTimerTask 一直在检测已经下线的Provider-122

Originally posted by @caichy in #1805 (comment)

[theonefx]

非常感谢，我们会尽量在正式release解决这个问题

[theonefx]

排查了一天，确定这个不是SCA这边的问题，有可能出在网络连通上，或者是dubbo上。
最后一个截图中 “Fail to connect to ” 是发生在 dubbo 网络中断重连的逻辑，这个是provider和consumer的直连，不通过注册中心。
麻烦确认一个问题，Provider-122和Consumer-122 两个应用，下面三个参数有没有设置正确：

• dubbo.protocol.id=dubbo
• dubbo.protocol.name=dubbo
• dubbo.protocol.port=20882
  尤其是最后一个参数 dubbo.protocol.port ，如果在同一个ip上的多个进程，一定要在配置阶段就分配好。
  期待你的反馈

[theonefx]

另外，SCA 的版本，建议升级到 2.2.5.RC2

[caichy]

排查了一天，确定这个不是SCA这边的问题，有可能出在网络连通上，或者是dubbo上。
最后一个截图中 “Fail to connect to ” 是发生在 dubbo 网络中断重连的逻辑，这个是provider和consumer的直连，不通过注册中心。
麻烦确认一个问题，Provider-122和Consumer-122 两个应用，下面三个参数有没有设置正确：

• dubbo.protocol.id=dubbo
• dubbo.protocol.name=dubbo
• dubbo.protocol.port=20882
  尤其是最后一个参数 dubbo.protocol.port ，如果在同一个ip上的多个进程，一定要在配置阶段就分配好。
  期待你的反馈

最后一个截图是Provider已经下线，Consumer还在尝试重连

port用的是-1，今天再用2.2.5.RC2测试一下

• dubbo.protocol.id 没有配置
• dubbo.protocol.name=dubbo
• dubbo.protocol.port=-1

[theonefx]

排查了一天，确定这个不是SCA这边的问题，有可能出在网络连通上，或者是dubbo上。
最后一个截图中 “Fail to connect to ” 是发生在 dubbo 网络中断重连的逻辑，这个是provider和consumer的直连，不通过注册中心。
麻烦确认一个问题，Provider-122和Consumer-122 两个应用，下面三个参数有没有设置正确：

• dubbo.protocol.id=dubbo
• dubbo.protocol.name=dubbo
• dubbo.protocol.port=20882
  尤其是最后一个参数 dubbo.protocol.port ，如果在同一个ip上的多个进程，一定要在配置阶段就分配好。
  期待你的反馈

最后一个截图是Provider已经下线，Consumer还在尝试重连

port用的是-1，今天再用2.2.5.RC2测试一下

• dubbo.protocol.id 没有配置
• dubbo.protocol.name=dubbo
• dubbo.protocol.port=-1

dubbo.protocol.port 不要用 -1 ，提前分配好
dubbo.protocol.id 也设置为 dubbo
辛苦再试试

[caichy]

dubbo.protocol.id=dubbo
dubbo.protocol.name=dubbo
dubbo.protocol.port=28888 / 29999

加上这些配置后没有变化，还是和之前一样
1、Provider已经下线，Consumer还在尝试重连

2、启动Provider-121实例，Consumer会收到通知，但请求不会打到Provider-121，日志如下：

[theonefx]

dubbo.protocol.id=dubbo
dubbo.protocol.name=dubbo
dubbo.protocol.port=28888 / 29999

加上这些配置后没有变化，还是和之前一样
1、Provider已经下线，Consumer还在尝试重连

2、启动Provider-121实例，Consumer会收到通知，但请求不会打到Provider-121，日志如下：

1. dubbo 本身没有拉黑机制，需要注册中心推送了最新的应用列表才会停止。
2. Consumer 在收到服务上线通知后，会拉取服务元数据信息，元数据的服务是随机选择的，所以打到哪个服务上都是有可能的。
   你这边使用的 nacos 的服务端版本是多少？1.4.1 吗？

[theonefx]

有什么联系方式，方便单独沟通一下吗？

[caichy]

有什么联系方式，方便单独沟通一下吗？

钉钉号：ztwrhde
nacos服务端刚升级了1.4.0

[megatronyy]

有什么联系方式，方便单独沟通一下吗？

我这边出现了跟这一样的问题

版本
sca：2.2.4.release
dubbo: 2.7.8
nacos-client: 1.4.1
nacos-server: 1.2.0

钉钉：megatronyy

[caichy]

目前已知的一个原因：同一个接口使用不同的@DubboReference配置时，Dubbo会为这个Service初始化不同的Invoker，对应的RegistryDirectory也不同，但是服务上下线只处理了其中一个RegistryDirectory实例，所以会导致Consumer在调用这部分接口时没有刷新到新的Provider，Provider下线了也不能及时清除。

如下，一个项目中对同一个接口有两种不同配置的Reference

[megatronyy]

目前已知的一个原因：同一个接口使用不同的@DubboReference配置时，Dubbo会为这个Service初始化不同的Invoker，对应的RegistryDirectory也不同，但是服务上下线只处理了其中一个RegistryDirectory实例，所以会导致Consumer在调用这部分接口时没有刷新到新的Provider，Provider下线了也不能及时清除。

如下，一个项目中对同一个接口有两种不同配置的Reference

我这边没有同一个接口使用不同的@DubboReference配置，但此问题还是存在

[theonefx]

@twfx7758 你是用的是哪个版本？

[megatronyy]

@twfx7758 你是用的是哪个版本？

版本
sca：2.2.4.release
dubbo: 2.7.8
nacos-client: 1.4.1
nacos-server: 1.2.0

[theonefx]

@twfx7758 你是用的是哪个版本？

版本
sca：2.2.4.release
dubbo: 2.7.8
nacos-client: 1.4.1
nacos-server: 1.2.0

升级到 2.2.5.RELEASE 应该就能解决你的问题了

[megatronyy]

@twfx7758 你是用的是哪个版本？

版本
sca：2.2.4.release
dubbo: 2.7.8
nacos-client: 1.4.1
nacos-server: 1.2.0

升级到 2.2.5.RELEASE 应该就能解决你的问题了

多谢，已升级，我们再观察下

[theonefx]

该issue先关闭了，如果还有问题，另提issue再继续；
The issue is closed first, if there are any problems, please raise another issue continuing;