Albumen Kevin
Albumen Kevin
Will be fixed in https://github.com/apache/dubbo/pull/11395
Would you pls submit a PR to enhance?
Pls go ahead
> i want to do but how? We should add some test cases to verify whether the verification and spring adaptation are as expected. Such as annotation, configurations...
看了下代码，目前 zk 接口级的实现是有这个问题的，是需要基于 `org.apache.dubbo.registry.RegistryNotifier` 去进行实现，不应该阻塞 zk 的通知线程
> 另外，想讨论延迟通知这个特性本身，会不会造成一些问题。例如，有 1-10、11-20、21-30 三组 Provider 实例，分批进行更新，进行一次上线更新之后，变成 31-40、41-50、51-60 三个 Provider 实例，延迟订阅的方式 会不会 出现部分 Provider 连接失败的情况，导致线上用户的请求失败。毕竟，延迟订阅的话，相当于和 Zookeeper 断开了 5 秒的时长。 是的，确实有这个问题，延迟通知这个功能是给超大规模集群设计的，避免推送风暴导致的增量内存突增。之前延迟推送也设计了前 10 次推送不等待的逻辑，我在想是不是我们需要加上一个地址数量的判断逻辑，如果数量少于某个值就直接推送。（此外对于并发推送的情况，我们需要加上对应的版本号，以此来防止覆盖）
Please try upgrade to 3.1.4