ARMv7环境下，会发生连接池泄露

[stitchcula]

用netstat -anp | grep 8888 | wc -l有3166个连接，最多时有2w多个。 使用方式如下

ssdbConn, err := store.ssdbPool.NewClient()
if err != nil {
    //log
    return err
}
defer ssdbConn.Close()

x86环境下未出现该问题，初步怀疑ARMv7下defer的实现有bug，正在验证。

[seefan]

确实没有在ARMv7下进行过验证，等待你的结果。 或者你把defer ssdbConn.Close()改成使用完连接直接调用ssdbConn.Close()试下

[stitchcula]

昨天也有两台x86服务器出现泄漏了，而且不是必现，非常蛋疼…

[seefan]

确认一下，你用的哪个版本，是release 1.0还是最新版的。 1、把defer ssdbConn.Close()改成使用完连接直接调用ssdbConn.Close()试下 2、提供一下golang和ssdb的版本

[seefan]

修正了一个解包的问题，你可以再试试是不是解决了你的问题。

[stitchcula]

用的是最新版，golang是最新的1.9，ssdb是内部定制修改过的。 新修正的版本还没试，已经换成了fork用go-common-pool的分支。 这个不是必现不好测试，单机压测了一天都没出现问题，大规模测试部署就总有那么几台泄漏。 业务代码没执行情况下的泄漏现场：

[stitchcula]

还有一个比较好复现的问题是：业务与ssdb正常连接、通讯后，关闭ssdb然后重启ssdb，gossdb连接池工作不是很正常，似乎不会重连，但有时候又会连一两个。 有空可以试下~

[seefan]

我更新了recv函数，因为我发现在某些情况下，ReadBytes会出现无法timeout的情况，这种情况应该会出现在数据中的结尾是\r\n的情况，我原来没有兼容这种情况。现在处理了两种结尾。

[seefan]

如果ssdb重启，会导致原有的连接失效。现在的处理机制是一但连接失效，就会在使用这个连接时引起错误，导致这个连接关闭，然后新建的连接就是正常的了。

所以，一但ssdb重启，会导致原来连接池里的连接全部失效。目前还没有加重试机制。

[seefan]

该问题可能是在读取连接数据或是写入连接数据时，网络出现了问题，导致读取或写入一直无法完成，所以连接会挂起。 已增加读写的超时时间控制，超时后会返回异常。

还有一些可能是网络命令解析出错，这个与其它问题合并处理。