ActiveMQ:No operations allowed after statement closed问题及解决办法

ActiveMQ版本:5.5.1
记录人:@郑昀

现象:

系统现象:部分消息发送失败,失败频率不正常。
日志信息:activemq.log 中一直有这样的错误日志:

JDBC FailureNo operations allowed after statement closed.

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed.

        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)

…………

        at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:227)

        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)

        at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220)

        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202)

        at java.lang.Thread.run(Thread.java:662)

Close failed: Already closed.

看上去又是 mq broker 失去了数据库连接,但代码仍尝试在此连接上执行操作,所以 jdbc 直接抛异常。


原因:
ActiveMQ 持久化方案我们选的是 MySQL 。
如果 mq 与 db 之间的数据库连接,因为数小时的不活动(inactivity),那么 MySQL 就会根据自身的 wait_timeout 参数设置主动断开连接。这一点在之前的“ActiveMQ:Communications link failure问题以及解决办法”文章中讲过。
只不过,遇到此问题时,
mq client 端报告“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure”错误,
而 mq server 端则报告“ com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed. ”错误。
即原因是,mq broker service 试图在已关闭的数据库连接上继续执行操作
缺陷单 AMQ-2534 甚至报告“

Broker gets stuck with an error about using a closed JDBC statement

”,我们很难说此时 mq broker service 会不会真的“卡住”。
 
解决办法:
“ActiveMQ:Communications link failure问题以及解决办法”文章讲的一样,
最简单办法,还是根据业务特点,调整 ActiveMQ 所使用的 MySQL 的全局变量 wait_timeout 值,
尽量减少数据库连接因为 inactivity 而被关闭的几率 
 
或者在 mq client 里主动捕获 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException 异常,手动重新连接即可:
  1.         } catch (SQLException sqlEx) {  
  2.             String sqlState = sqlEx.getSQLState();  
  3.            // 08S01就是这个异常的sql状态。单独处理手动重新连接即可。  
  4.             if ("08S01".equals(sqlState) || "40001".equals(sqlState))   
 

为什么 Connector/J 不自动重连而非要抛出异常:
下面的文字翻译自 MySQL 5.5 Connect/J 疑难问题文档
23.3.15.13: 为什么遇到 communication failure 之后, Connector/J 不能自己重新连上数据库,然后重新提交事务呢,而是非要抛出一个异常,即使我用了 autoReconnect 连接字符串属性?
答:有几个原因。
第一个,保证事务完整性。MySQL 的帮助文档上曾说过:“there is no safe method of reconnecting to the MySQL server without risking some corruption of the connection state or database state information”。
可以看一下这个案例:
01.conn.createStatement().execute(
  "UPDATE checking_account SET balance = balance - 1000.00 WHERE customer='Smith'");
02.conn.createStatement().execute(
  "UPDATE savings_account SET balance = balance + 1000.00 WHERE customer='Smith'");
03.conn.commit();
考虑一下这个场景:执行完01后,数据库连接断了。
如果没有异常抛出的话,应用程序永远不知道这个问题,仍继续执行。
但是第一个事务并没有提交,所以它回滚了。
如果没抛异常,数据库连接自动重连,于是第二个事务被提交了。
从而破坏了事务完整性(transactional integrity)
 
记住,此时 auto-commit 于事无补。当 Connector/J 遇到 communication problem ,你不知道服务器端是否处理了这个事务,有几种可能:
  • 服务器端没有接到这个事务,因此什么也没发生;
  • 服务器端接到了且执行了,但客户端没有收到 Response 。
 
第二个原因是,事务里上下文相关数据有可能非常脆弱,如:
  • 临时表;
  • 用户自定义变量;
  • 服务器端预处理语句(Server-side prepared statements);
如果数据库连接断开了,很可能这些数据也消失了;如果此时不抛出异常而是自动重连,你的应用程序很可能跑飞了。
 
总结:
1)silently reconnecting”可能非常不安全,将衍生出很多不可控问题。所以最佳策略是,通知应用程序到底发生了什么,然后由应用开发者决定如何处理
2)mq的生产者频繁报“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure”和mq server自己频繁报“com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed”,都是因为 mysql  wait_timeout 导致数据库连接因为不活动而被主动关闭。

 


参考资料:
 
posted @ 2012-11-10 00:30  老兵笔记  阅读(22806)  评论(0编辑  收藏  举报