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(),不做任何操作，用来进行连接池校验。
