shiyiyue1102
shiyiyue1102
现在对于限流和活性探测是放在一个逻辑里，其实可读性较差，针对这两种情况我们处理的逻辑是不一样的，对于活性探测，如果连接仍然存活，那么是不能直接驱逐的，如果连接不存活，那么就从连接管理器中删除掉，那么有可能进行活性探测之后，就没有超过限流了。逻辑应该是这样。 1.优化针对过期连接进行活性探测，对失活的连接进行剔除，剩下来的就都是健康的连接 2.针对健康的连接进行限流值校验，先判断单IP上限，对超限的进行驱逐 3.判断剩下的连接，如果超过总数上限，则进行随机驱逐
Yes, you are right, if the total count is no longer exceed the limit rule after active detection, we should not evict any connections.
不兼容的改动，需要升级表结构，不建议当前版本合入，可以下一次大版本中再考虑
what version of nacos-client do you use?
fix checkstyle pls.
这里v1 v2版本的后端处理接口不一致，是一个问题。 从后端接口的角度应该这样处理，发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空，表示接口已经对明文进行过加密，则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空，则通过加解密插件对content(此时认为参数中的content为明文，根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey
> > 这里v1 v2版本的后端处理接口不一致，是一个问题。 从后端接口的角度应该这样处理，发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空，表示接口已经对明文进行过加密，则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空，则通过加解密插件对content(此时认为参数中的content为明文，根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey > > Thanks for your answer.According to your reply, can I understand it this way: > > 1. V2 API is...
> > > > 这里v1 v2版本的后端处理接口不一致，是一个问题。 从后端接口的角度应该这样处理，发布接口接收content和encryptedDataKey。 如果encryptedDataKey 不为空，表示接口已经对明文进行过加密，则直接存储content(此时认为参数中的content已是密文)和encryptedDataKey 如果encryptedDataKey为空，则通过加解密插件对content(此时认为参数中的content为明文，根据插件中自定义规则判断是都需要加密)进行加密获得 加密后的content和encryptedDataKey > > > > > > > > > Thanks for your answer.According to your reply, can I understand...
EmbeddedConfigDumpApplyHook 这里针对批量删除的场景有bug，  @ZrBac 你本地测试下，把这个问题修复掉是不是就好了，如果可以的话，提交个PR