five111

### 针对这个问题，在vertx未升级的版本其实存在一个废弃连接的使用导致此问题发生 这种场景下和性能其实没有关系 很多时候在这个场景下去从性能入手找问题就走偏了 ### 这里提供一个比较容易触发的场景： - 使用servicecomb vertx升级之前的版本，我这里使用的2.1.5版本，同时通信模式都是使用的 servlet - 客户端开启一个定时任务，比如每隔{time}s发送一个请求到服务端， 这个{time}与服务端tomcat设置的断开连接时间要一直或相近比较容易触发 ### 我们通过抓包，发现了导致此问题的原因： 客户端复用连接池，在TCP连接四次挥手期间发送请求，会导致请求失败  ### 解决办法 1. 请求量少的可以用短连接 2. 我们请求量较大，通过重试机制去解决此问题 ### 复现demo ### 客户端： ``` // 起5个线程发请求...

1.3版本

这个日志记录的这次请求已经成功了啊

I'm not sure about the specific usage scenarios, can you provide a UT that can reproduce the problem

同样好奇这个问题 如果我只启动config的main方法 配置相关的特性是否都能具备

支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现）

> > 支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现） > > 建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦 https://github.com/alibaba/nacos/issues/9146 先建个issue 稍后几天 我将目前实现的思路和细节贴上来 然后讨论下适合社区发展的思路

> > > > 支持按组监听配置 解决的问题主要是： 客户端想监听某个一组下面的配置 比如 data_id为 nacos.common开头 group为 product开头的所有配置 当满足这个条件的配置发生了 新增 修改 删除 可以通知到客户端 （社区看看是否感兴趣 我们已经做了一套实现） > > > > > > > > > 建议很不错，这个社区有很多朋友也有类似需求，可以考虑开一个ISSUE来搞哦 >...

`// wait for response if (recAbilityContext.isNeedToSync()) { // try to wait for notify response recAbilityContext.await(this.clientConfig.capabilityNegotiationTimeout(), TimeUnit.MILLISECONDS); // if no server abilities receiving, then reconnect if (!recAbilityContext.check(grpcConn)) { return null; }...

> 这个是等待 `sdk` 和服务端同步彼此的能力信息，并不会影响到正常的连接注册流程。我在本地用 V2.1.0 的客户端和 V2.3.0 的服务端测试，貌似没有复现，如果可以的话，提供更多的信息 感谢回答！经过这两天调试发现不是不兼容 是我们打nacos服务端包的时候 少了jar包导致的 顺便问一下`sdk 和服务端同步彼此的能力信息` 这个能力老的客户端应该没有吧 这个的影响是什么 有兼容性风险 或者能力缺失啥的吗