wait_timeout

ActiveMQ版本：5.5.1 MQ 所使用的 MySQL 是 InnoDB存储引擎 记录人：@郑昀 现象： 业务表面现象：无。系统现象：无。 日志信息：业务系统发送 MQ 消息时，下面这种错误日志断断续续地一直都有： com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 60,001 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago. 原因： ActiveMQ 持久化方案我们选的是 MySQL 。 MySQL 的全局变量 wait_timeout 默认是28800，单位是秒，即8小时。 运维部早先在测试 ActiveMQ 5.5 主从方案时，发现当 Master 宕机后，锁（数据库里的一个排他锁）有可能没有释放，导致 Slave 无法成为 Master（ 这是 ActiveMQ 5.5 的 BUG ，已在 5.6.0和5.7.0 修复）。 所以运维部将 wait_timeout 参数调短为了 60秒 ，希望能加速锁释放。

###一、源起 同事在调试程序时遇到了Mysql异常 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:Communications link failure Last packet sent to the server was X ms ago ###二、分析 这是由于JDBC客户端的mysql连接在长时间不活动之后断开了，断开之后的首次请求会抛出这个异常。查询mysql超时设置:show variables like ‘%timeout%’，查看和连接时间有关的MySQL系统变量，得到如下结果： 他的一个查询程序跑了148秒，在同一个事务里再执行update操作时，程序抛出了上面的异常。 一开始我以为是在这个查询执行时间过长，mysql主动切断了连接。但是很奇怪的是在navicat单独执行这个sql，五六秒就能得到结果，虽然也很慢，但是没那么离谱。 这时候我怀疑，是不是结果在程序中早就查出来了，但是由于程序本身的原因，导致总的执行时间超过了wait_timeout设置的值，导致mysql server端切断了不活动的连接。 在验证这个问题时，由于同事的maven依赖很多，导致依赖关系非常乱。日志用的是log4j2，但是mvn dependency:tree查看到了很多log4j-1.2、slf4j各种桥接的依赖