MQ:Communications link failure

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

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秒，希望能加速锁释放。
当业务不繁忙时，也许会有60秒既不生产也不消费，因此 MySQL 主动断开了 Connection 。此时，如果作为 MySQL Client 身份的 Broker Service，它的数据库连接池对 连接断开检测和自动重连 做得不好的话，那么 Broker 首次访问 DB 时 jdbc 就会报错。

短期解决办法：
将 ActiveMQ 所使用的 MySQL 的全局变量 wait_timeout 恢复为默认值 28800 。（已完成）

中期解决方法：
将 ActiveMQ 升级到 5.6.0或5.7.0 稳定版本。

相关的BUG：
ActiveMQ 的缺陷单 AMQ-1958 报告：

JDBC master/slave deadlock when connection is lost

影响版本：4.1.2, 5.0.0, 5.1.0, 5.2.0
Fix版本：5.6.0
状态：2012年4月17日已修复

描述：
在一个纯 JDBC Failover 场景下（1 Master+1 Slave）：如果 Master 失去了数据库网络连接，数据库里的锁将不会释放。这样 Slave 不知道 Master 已不能执行任务，Slave 仍尝试不断获取锁；当 Master 重启后，它自己也无法获得锁，于是变身为 Slave；结果就是 0 Master+2 Slave 。
环境：Oracle 10，MySQL 5
（这也就是运维部在 ActiveMQ 5.5.1 测试场景所遇到的）

AMQ-3654 也报告类似问题：

JDBC Master/Slave : Slave cannot acquire lock when the master loose database connection

影响版本：5.5.0
Fix版本：5.7.0
状态：2012年6月13日已修复
描述：与 AMQ-3654 描述一样。只不过报告的版本号不一样。

参考资源：
1）火丁老王，MySQL里的wait_timeout

2）iteye，关于 MySQL 的 wait_timeout 连接超时报错解决方案
3）AMQ-1958
4）以前有人提议在数据库连接字符串中增加autoReconnect=true&failOverReadOnly=false，但这只对 MySQL 4.0 以前的版本有效，对 MySQL 5.0 以后无效。
5）ActiveMQ JDBC Master Slave帮助


6）wait_timeout 参数说明