wait_timeout

ActiveMQ:Communications link failure问题以及解决办法

荒凉一梦 提交于 2021-02-01 11:21:44
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超时异常的问题查询

风格不统一 提交于 2019-12-09 22:46:35
###一、源起 同事在调试程序时遇到了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各种桥接的依赖