请问为什么PushExecutorRpcImpl也是使用的ServicePushCallback，会导致无限次的失败重试，不受重试次数限制

[vanto-]

server：2.3.0 clieng：部分1.4.4，部分2.3.0，比例为：totalcount = 3296, detail {long_connection-1447, long_polling=1849}

发现naming-push.log中在持续打印push失败的日志，原因为push超时：

经排查，对应client版本为2.3.0，使用的PushExecutorRpcImpl，查看nacos 2.3.0代码，发现PushExecutorRpcImpl和PushExecutorUdpImpl都是使用的ServicePushCallback：

而ServicePushCallback看起来只针对udp push使用的，重试次数限制始终不会生效，导致无限次的失败重试

[Bo-Qiu]

较新版本的sdk 没有了定时从server查询的逻辑，要保证client和server的数据一致性，就需要依赖server端的推送机制，推送失败需要一直重试 直至成功。

[KomachiSion]

如果推送失败， 必须要进行无限次数的重新推送，直到推送成功，保证客户端订阅者和服务端之间的数据一致性，这是必须的机制，除非该客户端告知服务端不再订阅这部分数据，或连接断开。

建议你排查你的客户端为什么处理不了服务端的推送数据（比如CPU高、fullGC，类冲突等），或者网络是不是存在问题，导致推送数据一直不可达，或者客户端回的ack一直不可达。

[KomachiSion]

补充一下， 为什么UDP推送只重试2次：
因为UDP本身就是不保证送达的协议，因此从设计上，UDP协议仅作为补偿方式，1.X的客户端核心是依赖轮训查询的方式获取最新服务列表，因此UDP不是核心手段，只需要重试2次；

但是RPC推送是核心的手段，由于长连接和TCP链接的特性， 使用主动推送的方式更能提高性能和节约资源，且能保证送达，因此作为核心手段；同时作为核心手段，必须保证其数据的一致性，推送失败必须要重试，直至成功。

[vanto-]

补充一下， 为什么UDP推送只重试2次： 因为UDP本身就是不保证送达的协议，因此从设计上，UDP协议仅作为补偿方式，1.X的客户端核心是依赖轮训查询的方式获取最新服务列表，因此UDP不是核心手段，只需要重试2次；

但是RPC推送是核心的手段，由于长连接和TCP链接的特性， 使用主动推送的方式更能提高性能和节约资源，且能保证送达，因此作为核心手段；同时作为核心手段，必须保证其数据的一致性，推送失败必须要重试，直至成功。

但是我看到com.alibaba.nacos.core.remote.RpcPushService#pushWithCallback是有重试次数限制的逻辑的，不知道这是用在什么场景的，这是我比较纳闷的

[KomachiSion]

仔细看这个逻辑， 配置中心在超过重试此时之后，会尝试断开链接， 断开链接之后，客户端如果还正常，会尝试重连，重连之后会重新订阅，然后会重新推送； 这也就意味着其实还是无限次推送，直到推送数据成功。

注册中心之所以不进行连接断开， 是因为连接中不仅保存着订阅的信息，还保留着注册服务的信息， 如果断开链接会导致服务掉线。

[KomachiSion]

No more response from author, It seems usage problem.