就说圆圆好可爱

> 这个报错是在 offline 的过程中出现的还是进程 shutdown 的过程中出现的。另外使用的是 qos 的下线方式是通过 `offline` 命令还是 `shutdown` 命令。 用的 offline 命令，应该是在执行 SpringApplicationShutdownHook 过程中出现的，补充一下上下文日志 2022-10-10 17:28:26.145 [RID:] [traceId:] [SpringApplicationShutdownHook] INFO o.a.d.c.r.GlobalResourcesRepository [GlobalResourcesRepository.java:120] [DUBBO] Dubbo is completely destroyed,...

> 这个问题复现频率有多高，看起来是 Dubbo 已经反订阅后销毁了线程池了，Nacos 还是推送了数据 频率的话蛮高的，4个pod滚动部署有2个pod会出现这个报错，理论上 offline 指令发送后应该不会推送过来才对，毕竟我看到 dubbo 入口的流量已经没有了

> > > 这个问题复现频率有多高，看起来是 Dubbo 已经反订阅后销毁了线程池了，Nacos 还是推送了数据 > > > > > > 频率的话蛮高的，4个pod滚动部署有2个pod会出现这个报错，理论上 offline 指令发送后应该不会推送过来才对，毕竟我看到 dubbo 入口的流量已经没有了 > > 这个在本地能搭个复现的场景嘛 本地的话不太好模拟滚动部署，还有没有别的方式或者你这边还需要啥额外的信息

> > > > > 这个问题复现频率有多高，看起来是 Dubbo 已经反订阅后销毁了线程池了，Nacos 还是推送了数据 > > > > > > > > > > > > 频率的话蛮高的，4个pod滚动部署有2个pod会出现这个报错，理论上 offline 指令发送后应该不会推送过来才对，毕竟我看到 dubbo 入口的流量已经没有了 > > > >...

@AlbumenJ 我最近也遇到了这个问题，我的场景是这样的，消费端的 dubbo 版本是 3.2.0，jdk 版本是17，服务端的 dubbo 版本是 3.1.10，jdk版本是1.8，都在容器环境，注册中心是 nacos，当时服务端由于 oom 被 Kubernets 给 kill 了，后面消费端出现了很多 ReconnectTimerTask 尝试重连已经下线的消费端失败的错误日志，当时消费端应该有6个副本，这些错误日志集中在其中两个副本，然后我看了 3.2.0 的源码，你上面提到的 #10938 和 #11780 应该在 3.2.0 的版本都已经合进去了，能帮忙分析下为啥还会出现这个问题吗。

> 我遇到的情况至少持续了40分钟左右，因为40分钟之后我重启了有这个问题的消费端副本才解决这个报错

> 1. 服务端 kill 以后有重新拉起吗 > 2. 需要再复现的时候从日志看一下 Nacos 是什么时候推送的新地址，Dubbo 是否有关闭连接的行为 1. 重新拉起了 2. Nacos 推送新地址的时机不好判断，MSE Nacos 上只能看到有推送，但看不到推送的内容，服务端当时有这个日志：  消费端的报错是这个：  另外发现不是 OOM Killing 的，人为手动 Killing 也有这个问题