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

系统管理员 2021-05-12 11:55 603阅读 0赞

在实际的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做写入操作。   
这里让我们推测一下，首先该连接已经在服务器端被服务器端显示关闭了，而客户端无法感知该连接已经被关闭，为什么服务器端会将这个连接关闭掉呢？原因有很多，例如：

服务器keeplive心跳，检测发现客户端存活，但是网络不可达，服务器就会关闭这个连接  
连接由于其他原因，例如socket传输异常，导致服务器将这个连接关闭  
我们初步怀疑是第一种原因导致的，因为在这个问题发生时，我们的客户端所在的服务还在正常运行。   
下面我来看问题发生时的现象。   
客户端截图：   
![20190109191515323.png][]

根据图中，我们明显看到客户端处于CLOSE-WAIT状态，而根据TCP状态图，我们知道进入这个是个状态是由于被动关闭导致的，也就是说我们对应的thrift服务器端将这个socket连接关闭了，而服务器端会进入FIN-WAIT2/TIME-WAIT和CLOSED，这里我们把TCP交互图列举出来：   
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXhpYW83MjM4NDY_size_16_color_FFFFFF_t_70][]

服务端TCP状况截图：

![2019010919160968.png][]

通过截图，我们可以很清楚的看到服务端已经将这个连接关闭了，这也就印证了我们的猜测，是由服务器端主动关闭了连接，导致了该问题发生

thrift探究  
既然这个问题是由于thrift上报上来的，我们就去探寻一下thrift客户端的机制，看它是否能感知。通过源码分析得知（源码很多，就不具体列举了）thrift客户端是被动调用，由用户在需要的时候显示调用，进行RPC通讯，写入数据，然后读取返回值，这样就导致，即使服务端给客户端发送了fin挥手信息，他也不能处理，这样也就无法有效将这个连接关闭掉，而是由对象池在实际使用中进行检测，关闭这个失效的连接，对象池也只是管理了这个socket句柄，并没有对FIN的处理。  
在thrift服务器端，我们分析查看了源码，发现，服务器端也没有针对长连接长时间不适用的应用程序的超时控制  
结论  
经过上文排查，基本怀疑是socket异常导致内核主动关闭连接或者心跳检测异常关闭连接，后续会针对这两种情况进行试验验证

[20190109191515323.png]: /images/20210511/93a41215a8c34f30947b27b1391d5a7d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdXhpYW83MjM4NDY_size_16_color_FFFFFF_t_70]: /images/20210511/51da589fe7f7419e8f9299fea74bcf40.png
[2019010919160968.png]: /images/20210511/bdfa2e9cd65b4235a53909da0c2f8a82.png