Get 从连接池中获取的连接失效

[achst]

假如连接池初始化后，连接的服务方关闭了，连接池中的所有连接就失效了。 因此，每次调用 Get 方法获取连接池中的一个连接时，需要类似 ping 的检查，失效的时候重新创建连接。

建议： 初始化的时候提供一个 Ping 方法，类似 factory close 的。

[silenceper]

取到链接后，是否失效是使用者来判断，而且即便是全部失效，pool中的链接肯定不会主动去生成。

可以优化的一个点就是就是在Get中，判断连接是否失效，这个失效的判断，由使用者实现(将ping暴露出来)

[achst]

就是这个意思，如果初始化的时候暴露这个口子，就更加通用了。希望您采纳，把 ping 的口子暴露出来，多谢！

[silenceper]

也欢迎 pr啊 🤣

[achst]

也欢迎 pr啊 🤣

我刚改了我本地的代码，如果测试没有问题，就提 pr。

[hopehook]

pr 已经提了，后续我会继续关注，如果有任何问题，我再反馈。

[silenceper]

@hopehook nice 👍 👍 晚点我看下

[silenceper]

fixed #6

[hopehook]

1 关于 Ping 这个 ping 本身不是强制的, 如果有这个机制支持, 是可以解决这个问题的. (当然, 会影响连接池的高效, 连接池的目的就是避免 tcp 3 次握手, 4 次挥手的代价. 而 ping 在这里实际上也是一个报文, 会有 2 次数据传输交互的开销)

2 关于 Connect 为了高效, 和在 thrift 中使用连接池, 我多加了这个 Connect 方法, 解决了我碰到的连接失效的问题, 也解决了高效的问题.

我也看过您关于 thrift 连接池的博文, 好像最后没有解决这个问题. 我把自己处理的方式, 写在博文里面了, 您看看, 交流交流. (https://hopehook.com/post/golang_thrift_client_pool/)

[silenceper]

1、ping这个方法没有问题，在使用时检测连接是否有效 有时候也是需要的，只是我觉得，这个判断的操作应该放在用户端，像你封装的这个Call 2、看了下你这个处理，通过maxBadConnRetries，alwaysNewConn 控制 这个学习了

[hopehook]

1、ping这个方法没有问题，在使用时检测连接是否有效 有时候也是需要的，只是我觉得，这个判断的操作应该放在用户端，像你封装的这个Call 2、看了下你这个处理，通过maxBadConnRetries，alwaysNewConn 控制 这个学习了

所以 Ping 这个方法我没有暴露出来, 不是强制的. (如果您觉得多余, 移除也是没问题的) maxBadConnRetries，alwaysNewConn 控制这个实际上是借鉴的 golang 标准库的做法, 目前处理这种连接失效的最好做法可能就是调用失败的时候, 重试, 重试失败的时候重新建立连接.

如果这么做的话, 我就需要一个 Connect 方法, 要不然没法建立新连接.

[ltinyho]

个问题. 我把自己处理的方式, 写在博文里面了, 您看看, 交流交流. (http://hopehook.com/2018/09/17/golang_thrift_client_pool/)

http://hopehook.com/blog/golang_thrift_client_pool 最新链接,原链接失效了