thrift无法判断连接失效的原因与解决方案

       公司的软件系统使用thrift来进行系统内部各服务的沟通调用。thrift客户端采用了连接池的方式减少连接频繁创建销毁产生的开销。连接池之前一直存在无法即时判断连接是否有效的问题。今天抽空看了下thrift的源码，分析出原因如下：

    我们在程序中判断连接是否有效时，调用的是 TTransport类的isOpen()函数

   

   一路调试跟踪查看 TTransport的isOpen()源码，得到如下：

   

  即最终调用的是jdk中 Socket类的isConnected()方法

 

   根据源码中的英文注释内容及网上的资料，得出答案： isConnected方法得到的并不是Socket的当前连接状态，而是只要是Socket连接曾经成功过，isConnected始终返回true。

   Thrift并没有提供一个可以获取当前连接状态的方法。

   之前连接池的解决方案是：在当前远程调用操作失败后，将失败状态写入当前客户端类变量，下次校验时，查看此变量，获取连接状态，销毁重连。这样导致的结果是异常连接总会失败一次，当连接池中缓存的异常连接过多，就会造成过多的业务请求失败，且单独服务的重启操作需要也重启依赖此服务的程序，避免失败，很麻烦。

   这次采用的解决方案为：各个服务thrift服务端统一新增一接口函数，名为ping()(或其他名称），ping()函数中什么也不操作。这样连接池在校验连接时，统一调用各服务的ping()即可精确得知连接状态（调用ping()失败即连接异常，调用成功即连接正常）。由于ping()为空，不进行任务业务操作，对服务端造成的压力也会很小。