ActiveMQ LevelDB/Zookeeper bug

ActiveMQ问题排查

问题出现前使用activemq 5.11.1，排查问题中改用5.13.3：

• 背景
• 排查经过
• 结果
• 解决方案
• 总结

---

背景

公司内使用ActiveMQ(以下简称“MQ”）作为消息中间件进行模块间的消息传递。特别地，我使用MQ作为实时检索系统增量接收的消息中间件。MQ按Replicated LevelDB Store + zookeeper master/slave方式部署。

一开始上线并没有发现什么问题，过了大概一个月，发现线上增量无法及时更新了。通过MQ的console查看发现队列的pending消息数保持在4000多，几乎不会变，偶尔会上下跳动1。

由于是线上服务，想着尽快恢复线上服务，想到了重启，然而简单地执行以下命令重启MQ服务，

> cd /home/work/MQHome
> ./bin/linux-x86-64/activemq stop
> ./bin/linux-x86-64/activemq start

重启失败，囧。。

看了下MQ的日志，好像是3台机器间数据同步出了问题，那删了所有数据重启吧

> ...
> rm -rf data # 好危险，慎用！！！
> ./bin/linux-x86-64/activemq start

重启成功，线上服务算是恢复了（不过应该是丢了数据），开始排查问题了

排查经过

这时才发现线上日志也给删掉了（在data目录里），无语。。

遇到问题首先想的是能以最快的速度解决问题。考虑到MQ是开源软件，而且社区比较活跃，抱着试试看的态度查看了MQ的发布记录，确实MQ有大版本更新。于是，我们第一时间做了升级，从5.11.1升到5.13.3。不幸的是，同样的情况在大概3周后又出现了。TT

没办法，线下复现吧。

在一台线下机搭了MQ服务，首先怀疑是压力过大把MQ压垮了。通过console发送消息

然而以10000的压力，压了半小时，并没有压垮，而线上远远没到这个压力，故压力过大的情况暂时排除。

进而怀疑是写queue客户端的问题，使用线上的客户端代码做压测，压了半小时，仍然没有出现问题。

单机部署的情况都很稳定，有了第三个怀疑：集群部署方式有问题。因为线下没有3台物理机，故尽管有这个怀疑，也迟迟没有做验证。排除了以上两种可能，只能在做这第三个怀疑的验证了。在提供线上服务的3台机器上，另外搭了一套MQ，与线上服务MQ仅端口不同。

继续压测，悲剧的是，压测了半个小时仍然没出问题，怀疑是压的时间不够，便又继续压了两天，还是没出问题。

这次是真的没办法了，只能线上复现了，若线上复现，保留好现场，然后分析日志。

幸运的是，线上环境在重启后3周复现了，重点日志如下：

结果

将日志相关内容在google中搜索一番后，发现
https://issues.apache.org/jira/browse/AMQ-5082
这个问题早在14年3月5日就有人提过，现在还是open状态。（发稿时已是closed，并标记为won’t fix)

在官网搜索一番发现，

进一步发现，
http://blog.klocwork.com/open-source/activemq-community-deprecates-leveldb-what-you-need-to-know/

官方将不再维护LevelDB部署方式，包括leveldb/zookeeper方式。对于现有的bug也不再修复。

解决方案

最终只能采取一种临时方案，监控MQ的状态，发现不能正常写入MQ时，则重启MQ。

接下来考虑采用公司内部的nfs部署master/slave集群。

总结

整个问题追查及修复的过程发现：
1）线上环境不一致（java环境不同），不利于系统的维护；
2）出现问题时，未能保留好现场，对于这种非稳定复现的问题，保留好现场对定位问题是至关重要的；
最后，想说的是，在使用开源软件之前还是应该多看看官方文档，注意官方用语，“recommend”什么，”should”怎样

我们崇尚技术，追求新的技术，但在生成环境做类似的尝试还是要慎重再慎重。

---