activemq中参数maxReconnectAttempts是个大坑

现象：

     8月13日同事在测试session-clean-task工具时，发现工具起动后跑着跑着就不跑了，具体情况为：

     1）分配callid的任务还在跑

     2）从队列中获取callid并处理会话的线程不跑了

处理过程：

     1）因没有异常日志，所以怀疑是redis堵了

          操作：

               在从redis队列OnlineSessions_HandingList中获取数据时，如果callid为null，则打日志

          结果：

               重启工具后未见取出的callid为null的日志

     2）因工具的代码中每一个方法、while循环内部都作了try catch异常捕获，不至于这个都会有问题吧（即使有，至少目前没碰到过）

          另外看了看application.properties的配置，发现redis.timeout=60超时时间太短，于是改成了2000ms

          重启工具后，咦好像正常了，可是跑着跑着又不动了

     3）实在不行，开始加日志

          操作：

               在SessionCleanService类中每一个小的逻辑块加一个info日志： task + "---1"    task + "----2" 这样的

          结果：

               每次线程停住时，都指示问题出现在记录数据库会话日志那块

               

 

               确定是数据库操作卡住了，但是袁园过来说明 log_user_session 表中的数据量非常少

               登陆数据库后发现确实如此

     4）继续查找：

               进入logservice.java文件中查看代码，发现在异常后只记录了数据库日志，没有文本日志打屏

               而log_flow_engine_exception表中也没有日志，认为是logging-job没有部署，导致消息未转储所致

               操作：

                    为了方便查看日志，就在异常时打了一个logger.error

               结果：

                    确实记录数据库日志时存在异常，但是异常内容我再现网也见到过，但是现网是正常的啊：

                    

 

                    但是这个异常日志一旦打出来就应该会返回一个false，然后继续往后走才对啊

     5）接下来，把目光定位到了工具往mq里面写异常日志的代码了：

          

          为了验证mq是否存在问题，先是检查了mq的链接串，发现有一个地址链接不上，但是理论上一个地址链接不上也不应该出问题啊

          即便如此，还是把链接不上的地址给去掉了，再次重启，发现问题依旧

     6）在往mq里面记录日志的前后也加了logger.info日志，发现确实在到了记录日志的代码后，后面的日志就再也没打出来了

     7）查看mq的管理系统，发现累计的日志达到了200多W，然后就想，及时mq满了也不应该导致工具一直等在那吧

          后来上网查看mq链接串中的参数说明，就发现端倪了：

          maxReconnectAttempts为-1时，不限制重试次数，也就是说工具会等在那里知道异常信息塞进去！！！

          后来点击了管理页面上mq队列的purge操作后，工具立即就开始运行了。。。

          这个参数一定要改过来，比如重试三次，否则一旦mq满了或者出现问题，所有业务就中断了，以为所有流程引擎都会往mq写日志

          其他业务组件也是