Thrift java.net.SocketException: Broken pipe问题分析定位

在实际的thrift使用过程中,thrift客户端跟服务端通讯会有时爆出org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe异常,复现概率不高,很是困惑不知道是由什么原因引起的,在此记录一下分析和定位的过程,以备查看。

环境:

-centos 7
-jdk1.7
-thrift 0.9.1
-连接管理使用的对象池

问题产生的原因

这个异常产生的原因为thrift客户端向一个已经关闭的socket,写入数据导致该异常发生,在我们的客户端表现为client从对象池获取一个TCP长连接,然后在这个长连接上给服务端发送校验,校验连接是否存活,在实际写入探测字符串的时候,该异常发生,由TIOStreamTransport类在flush的时候抛出,关健的问题点在于客户端向一个已经关闭的socket做写入操作。
这里让我们推测一下,首先该连接已经在服务器端被服务器端显示关闭了,而客户端无法感知该连接已经被关闭,为什么服务器端会将这个连接关闭掉呢?原因有很多,例如:

  1. 服务器keeplive心跳,检测发现客户端存活,但是网络不可达,服务器就会关闭这个连接
  2. 连接由于其他原因,例如socket传输异常,导致服务器将这个连接关闭

我们初步怀疑是第一种原因导致的,因为在这个问题发生时,我们的客户端所在的服务还在正常运行。
下面我来看问题发生时的现象。
客户端截图:
这里写图片描述
根据图中,我们明显看到客户端处于CLOSE-WAIT状态,而根据TCP状态图,我们知道进入这个是个状态是由于被动关闭导致的,也就是说我们对应的thrift服务器端将这个socket连接关闭了,而服务器端会进入FIN-WAIT2/TIME-WAIT和CLOSED,这里我们把TCP交互图列举出来:
Thrift java.net.SocketException: Broken pipe问题分析定位_第1张图片
服务端TCP状况截图:
这里写图片描述
通过截图,我们可以很清楚的看到服务端已经将这个连接关闭了,这也就印证了我们的猜测,是由服务器端主动关闭了连接,导致了该问题发生

thrift探究

  1. 既然这个问题是由于thrift上报上来的,我们就去探寻一下thrift客户端的机制,看它是否能感知。通过源码分析得知(源码很多,就不具体列举了)thrift客户端是被动调用,由用户在需要的时候显示调用,进行RPC通讯,写入数据,然后读取返回值,这样就导致,即使服务端给客户端发送了fin挥手信息,他也不能处理,这样也就无法有效将这个连接关闭掉,而是由对象池在实际使用中进行检测,关闭这个失效的连接,对象池也只是管理了这个socket句柄,并没有对FIN的处理。
  2. 在thrift服务器端,我们分析查看了源码,发现,服务器端也没有针对长连接长时间不适用的应用程序的超时控制

结论

经过上文排查,基本怀疑是socket异常导致内核主动关闭连接或者心跳检测异常关闭连接,后续会针对这两种情况进行试验验证

你可能感兴趣的:(thrift)