如何解决JDBC死链接导致NIFI线程假死

现象

ExcuteSql不工作不调度，stop也停止不了，active的任务个数也不降低。

场景复现

1、模仿现场构造数据

2、Tc命令模拟现场网络环境模拟丢包30%

tc qdisc del dev enp4s0f0 root netem loss 30%

问题排查

netstat -pan | grep $NIFI_PID

可以看到和数据库开启了5个tcp连接，也可以看到有五个socket处于连接状态

直接看线程

jstack -l $NIFI_PID | grep 'java.net.SocketInputStream.socketRead0(Native Method)' -C 10

观察了一段时间，socket仍然没有关闭，可以基本肯定现场环境应该已经复现。

问题分析

一次完整的数据库请求包括三个阶段：

1、建立连接

2、数据传输

3、断开连接connect timeout:如果与服务器(这里指数据库)请求建立连接的时间超过ConnectionTimeOut，就会抛 ConnectionTimeOutException，即服务器连接超时，没有在规定的时间内建立连接。

socket timeout:如果与服务器连接成功，就开始数据传输了。如果服务器处理数据用时过长，超过了SocketTimeOut，就会抛出SocketTimeOutExceptin，即服务器响应超时，服务器没有在规定的时间内返回给客户端数据。

在未设置超时时间场景下，nifi通过jdbc获取数据库数据，本质是操作系统在调用Socket.read()，如果网络问题被阻塞住，那么操作系统会很少在调用Socket，java培训由于底层没有数据交互，那么其无法知道对端是否宕机，所以会一直等待。

难道系统没有默认的socketTimeout？

有的，上述场景下内核会在一个socket两个小时都没有数据交互情况下(可设置)启动keepalive定时器来探测对端的socket。

也就是说出现假死会在7875秒后恢复，大概两个多小时吧。

这就是nifi端线程假死的原因；

结论

JDBC的socket未设置超时，出现了死连接。

JDBC 驱动是用 Socket 方式与数据库连接的，应用程序和数据库之间的连接超时并不是由数据库处理的。

当数据库突然宕掉或发生网络错误（设备故障等）时，JDBC 驱动的 Socket 超时的值是必须的。由于 TCP/IP 的结构，Socket 没有办法检测到网络错误，因此应用不能检测到与数据库到连接断开了。如果没有设置 Socket 超时，应用程序会一直等待数据库返回结果。（这个连接也被叫做“死连接”）为了避免死连接，Socket 必须要设置超时时间。Socket 超时可以通过 JDBC 驱动程序配置。通过设置 Socket 超时，可以防止出现网络错误时一直等待的情况并缩短故障时间。
在timeout为0的时候，走默认的系统调用不设置超时时间的逻辑。在timeout>0时，将socket设置为非阻塞，然后用select系统调用去模拟超时,而没有走linux本身的超时逻辑。

解决措施

设置socket和Connection的超时时间。

防止因为网络问题出现死连接，给数据库的访问url加socket timeout和Connection timeout。