Druid连接池中出现15分钟延迟，疑似因Socket超时后重新建立连接所致

在应用端通过mybatis的interceptor自定义Plugin拦截Executor, 统计输出sql的执行耗时。

今天生产发生一个很奇怪的问题&＃xff1a; 莫名其妙卡顿15分钟&＃43;&＃xff0c;其后正常返回sql正常结果&＃xff01; 使用druid版本是1.0.2。。。。。

 统计发现&＃xff1a;

1. 出现该情况的单量有6笔&＃xff0c;集中在特定的2个小时之内&＃xff0c;都是查询sql&＃xff1b;都发生在1台应用服务器上。
2. 在这几笔订单卡住的时间内&＃xff0c;轮询任务触发又正常查询成功并正确处理成功&＃xff01;
3. 数据库层面没有慢sql&＃xff1b;且数据库实例的指标监控稳定&＃xff0c;应用监控除sql耗时监控异常外&＃xff0c;其他一切正常。
4. 日志没有输出error

推测是否是在getConnection过程中出现了等待。但因获取连接时的日志过少找不到具体的原因&＃xff01;

网上的类似问题说的原因是Druid在从连接池中获取的连接&＃xff08;代码详见&＃xff1a;DruidDataSource的getConnectionDirect&＃xff09;&＃xff0c;在开启testWhileIdle时&＃xff0c;如果活跃时间距离当前比较久&＃xff0c;那么将验证该连接是否有效&＃xff0c;无效会discardConnection并再次去pool内获取。

这个过程可能被数据库层面的防火墙策略已经关闭该连接&＃xff0c;而客户端还傻傻的发sql验证直到超时。。。。

在该测试连接的方法中有一个查询超时超时时间&＃xff1a;validationQueryTimeout。测试中是-1, 执行的是默认时间。。。。这个默认时间没有找到!! (有找到MappedStatementConfig由SqlMapConfiguration的defaultStatementTimeout)

应用与数据库间的timeout层级实例:
转帖&＃xff1a; 深入理解JDBC的超时设置

 上层的timeout依赖于下层的timeout&＃xff0c;只有下层的timeout无误时&＃xff0c;上层的timeout才能确保正常。eg.  当socket timeout出现问题时&＃xff0c;上层的statement timeout和transaction timeout都将失效。
 statement timeout 无法处理网络连接失败时的超时&＃xff0c;它能做的仅仅是限制statement的操作时间&＃xff1b;网络连接失败时的timeout必须交由JDBC来处理&＃xff1b;JDBC的socket timeout会受到操作系统socket timeout设置的影响。

1. Transaction Timeout&＃xff1a; 一般存在于框架&＃xff08;Spring, EJB&＃xff09;或应用级。spring在配置事务切面的时候可以配置timeout。

2. Statement Timeout&＃xff1a; 通过调用JDBC的java.sql.Statement.setQueryTimeout(int timeout) API进行设置。 以myBatis为例&＃xff0c;statement timeout的默认值可以通过sql-map-config.xml中的defaultStatementTimeout 属性进行设置。同时&＃xff0c;也可以设置sqlmap中select&＃xff0c;insert&＃xff0c;update标签的timeout属性&＃xff0c;从而对不同sql语句的超时时间进行独立的配置。

3. JDBC的statement timeout&＃xff1a;  通过调用Connection的createStatement()方法创建statement来executeQuery时&＃xff0c;会注册一个 TimerTask ->CancelTask 用来给Timer -> ConnectionImpl.getCancelTimer()来处理timeout事项&＃xff1a;发送 "KILL QUERY” 。 代码详见&＃xff1a; StatementImpl 及 ConnectionImpl

4. JDBC的socket timeout&＃xff1a; 
   

   1. 由于TCP/IP的结构原因&＃xff0c;socket没有办法探测到网络错误&＃xff0c;因此应用也无法主动发现数据库连接断开。如果没有设置socket timeout的话&＃xff0c;应用在数据库返回结果前会无期限地等下去&＃xff0c;这种连接被称为dead connection。 为了避免dead connections&＃xff0c;socket必须要有超时配置。socket timeout可以通过JDBC设置&＃xff0c;socket timeout能够避免应用在发生网络错误时产生无休止等待的情况&＃xff0c;缩短服务失效的时间。不推荐使用socket timeout来限制statement的执行时长&＃xff0c;因此socket timeout的值必须要高于statement timeout&＃xff0c;否则&＃xff0c;socket timeout将会先生效&＃xff0c;这样statement timeout就变得毫无意义&＃xff0c;也无法生效。
      eg.   jdbc:mysql://xxx.xx.xxx.xxx:3306/database?connectTimeout&＃61;60000&socketTimeout&＃61;60000

5. 操作系统的socket timeout配置

   
    

番外

MySQL JDBC的queryTimeout的一个坑

在该文章中说Statement.setQueryTimeout : 如果设置的超时时间过长&＃xff0c;在当大批量的SQL同时执行时&＃xff0c;每一个SQL都会创建一个CancelTask对象&＃xff0c;虽然很快执行完&＃xff0c;且会调用CancelTask.cancel()方法&＃xff0c;但是CancelTask方法的源代码仅仅是将自己的状态修改为&＃xff1a;CANCELLED&＃xff0c;而并不会直接从队列中移除这个对象, 导致OOM。 建议在cancel()后需要purge一下。

解&＃xff1a; MySQL Connector Java 5.1.44  版本 的 StatementImpl 已经有了purge&＃xff1b; 且 在1.8版本的JDK对Timer的cancel()也增加了移除queue内容

Timer

public int purge() {int result &＃61; 0;synchronized(queue) {for (int i &＃61; queue.size(); i > 0; i--) {if (queue.get(i).state &＃61;&＃61; TimerTask.CANCELLED) {queue.quickRemove(i);result&＃43;&＃43;;}}if (result !&＃61; 0)queue.heapify();}return result;}
}public void cancel() {synchronized(queue) {thread.newTasksMayBeScheduled &＃61; false;queue.clear();queue.notify(); // In case queue was already empty.}} 类似问题

通过网上blog查找发现有相似的问题存在&＃xff1a;

1. https://www.oschina.net/question/1450045_2157629
   

2. https://www.2cto.com/database/201505/402016.html
   

3. 在issues中搜索druid的testWhileIdle问题: https://github.com/alibaba/druid/issues/1260