Yang,Liming
Yang,Liming
@Huixxi 能给解释一下，当前的代码是因为bug还是因为设计上导致的E112无法恢复吗？想知道根音，然后目前的方案是解决设计问题，还是做一个兜底。
> > @Huixxi 能给解释一下，当前的代码是因为bug还是因为设计上导致的E112无法恢复吗？想知道根音，然后目前的方案是解决设计问题，还是做一个兜底。 > > 这个是当时把冰哥的内部patch搬运了出来，我理解还是设计上的问题，估计要彻底解决得大改，这个pr还只是个兜底在连接池和长连接的场景下。 收到
那通过健康检查来兜底可行吗？或者使用熔断策略，或者tcp keepalive这些能避免这个问题吗？
> > 备用Socket这里还有个问题，采用什么连接策略？比如原来是单连接，那么备用Socket也是单连接，还是说退化成一个临时的短连接？如果备用Socket也是单连接，管理起来比较复杂，如果退化成短连接，可能会导致性能下降或给后端带来太大压力？ > > 备用Socket还是通过SelectOut::ptr返回给调用方。调用方将其当做main socket用。连接策略是由调用方使用方式决定即可。在调用方看来，备用Socket应该跟naming service下发的Socket并无区别。应该可以加多一个备用Socket的SocketMap，相同Channel不用LB复用Socket，连接数不会增加很多，不会给后端带来太大压力。 > > 相比之下，SingleSocketPool的方案更好，将Socket管理逻辑收敛到main socket中，LB只需要实现恐慌策略，简化LB的实现逻辑，这样对于用户定义的LB更友好。 > > > 怎么判断实例是完全不可用呢？比如某一次连接ECONNREFUSED，后面再连有可能就成功了 > > Failed Socket在健康检查成功之前可以看作是不可用吧。如果是能连成功的话，健康检查成功，就Socket就会恢复了。 > > SingleSocketPool的方案将屏蔽状态和连接状态区分开来，更清晰了。 > > > 我在想能不能把SocketPool的逻辑稍微改一下，变成SingleSocketPool： > > GetSocket的逻辑：...
> > 这个方案的pr啥时候提出了？ > > 目前写了个大概，还需要再完善一下和补充UT。尽量下个版本支持恐慌策略。 👍，这个就相当于把遗留的一个bug就完全解决了吧。
这个问题有结论了吗？你们内部会创建一些基于timer调度的任务吗？
don't format file, just format what you changed
调用mysql的异步接口，然后只用 condition_variable countdown_event这些阻塞等待应答？应答后唤醒？
@Tuvie 辛苦评估一下，另外，我想再加个问题，现在的rdma可以配置成polling模式吗？或者增加这样的模式可行吗？
我看test下面那个BUILD.bazel里面的测试不全，有很多ut文件都没覆盖到，可以更新的全面一些吗？ @oathdruid