现象：
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写日志
其他业务组件也是