1、thrift无法判断连接失效

问题

使用thrift进行内部服务调用时，一般使用连接池的方式来减少连接频繁创建销毁产生的开销。thrift是无法判断连接是否有效的。

thrift判断是否有效。判断连接是否有效，使用TTransport类的isOpen()函数进行判断，isOpen()函数的源码中使用了jdk中Socket类的isConnected()方法判断。

jdk源码如下：
/**

* Returns the connection state of the socket.

*

* Note: Closing a socket doesn't clear its connection state, which means

* this method will return {@code true} for a closed socket

* (see {@link #isClosed()}) if it was successfuly connected prior

* to being closed.

*

* @return true if the socket was successfuly connected to a server

* @since 1.4

*/

public boolean isConnected() {

    // Before 1.3 Sockets were always connected during creation

    return connected ||oldImpl;

}

所以，isConnected方法得到的并不是Socket的当前连接状态，而是只要是Socket连接曾经成功过，isConnected始终返回true。

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

解决方案

    1、连接池中对象的active时间与server端的socket超时一致，避免获取到被关闭的连接（我们使用的方案）。

    2、远程调用操作失败后，讲失败状态写入当前客户端变量，下次校验时，查看此变量，获取连接状态，销毁重连。这样导致的结果是异常连接总会失败一次，当连接池中缓存的异常连接过多，会造成过多的业务请求失败。

    3、各个服务thrift服务端统一新增接口函数ping(),不做任何操作，用来进行连接池校验。