现象
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的超时时间。
文章图片
【如何解决JDBC死链接导致NIFI线程假死】防止因为网络问题出现死连接，给数据库的访问url加socket timeout和Connection timeout。
