ActiveMQ 从不删除 kahadb .log 文件；没有通过 JSP 接口可见的待处理消息；如何检测罪魁祸首？

Posted 2023-03-10

【中文标题】ActiveMQ 从不删除 kahadb .log 文件；没有通过 JSP 接口可见的待处理消息；如何检测罪魁祸首？

【英文标题】：ActiveMQ never deletes kahadb .log files; no pending messages visible through JSP interface; how to detect culprit?

【发布时间】：2014-11-05 03:25:02

【问题描述】：

我们在 CentOS 上运行 ActiveMQ 5.7.0。大约 50 个 Java 程序写入和消费队列，其中大约一半来自本地主机，其余分散在远程客户端，大多数每个进程有一个消费者，但四个有 32 个。

几天前，ActiveMQ 停止从 data/kahadb 中删除 .log 文件。如果重新启动，ActiveMQ 会从 kahadb 中删除所有内容，然后在运行期间不删除任何其他内容。

通过 [host]:8161/admin/queues.jsp 的 Web 界面没有可见的待处理（即排队但未出队）消息。 DLQ 为空，删除不影响问题。 （也从界面中收集到：所有连接都处于活动状态，没有一个很慢，没有订阅者，没有网桥，没有调度程序。）

关注http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html，我得到了以下信息：

|追踪 |最后更新：236:28401525，完整的 gc 候选集：[89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100 , 236 | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ 日志 检查点工作人员 2014-09-11 08:50:03,384 |追踪 | GC候选人 在第一个 tx:89:10178611, [] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ 日志 检查点工作人员 2014-09-11 08:50:03,384 |追踪 | gc 候选人：[] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ 日志 检查点工作人员

其中 db-89.log 是 ActiveMQ 重启后创建的第一个日志文件，而 db-236.log 是当前存在的最新文件。

ActiveMQ 日志中没有其他错误或警告。关于使用队列的程序，没有一致报告的异常。根据他们的日志，我公司在 localhost 上的程序正在发布交易。如果第三方程序没有发布交易，我不知道如何找出来。

鉴于这一切，我如何确定或缩小问题的可能原因？还有哪些有用的信息？

作为附加限制，访问客户端计算机及其程序是一个业务问题。我在那里没有帐户，并且管理员在不同的国家/地区，这会减慢沟通速度。如果我必须联系他们，我想提前向他们提供所有可能的信息。

非常感谢。

【问题讨论】：

我希望看到保存跟踪中提到的日志的目的地。你的 KahaDB 设置是什么？这是否需要时间才能发生或文件是否在重新启动后开始构建？您有使用持久主题的订阅者吗？最后，这是一个独立的代理还是主/从配置？

为了后代：文件立即建立。没有订阅者使用持久主题。这是一个独立的经纪人。我不确定哪个 kahadb 是相关的； kahadb 开箱即用，无需我们进行额外配置。

【参考方案1】：

我们通过研究 ActiveMQ 源代码来理解片段解决了这个问题：

第一个 tx:89:10178611 之后的 gc 候选人

原来，89 是日志文件名（db-89.log），10178611 是文件中的偏移量。所以，我们转储了日志文件：

xxd -g1 db-89.log | less

然后我们对偏移量进行了文本搜索（转换为十六进制）。在转储中，有一个人类可读的队列名称和一个挂起的事务以及它来自的服务器。

我无权访问有问题的服务器或代码，但管理员非正式地告诉我，他们的开发人员“修复”了交易的关闭，无论修复可能是什么。这样就解决了问题。

【参考方案2】：

我有一个类似的场景，结果消息被卡在 DLQ 中，没有人愿意监视它们......：S

提示：检查 DLQ！

你的解决方案，我也尝试过，我的线路是这样的：

2014-11-19 12:01:33,964 [eckpoint Worker] TRACE MessageDatabase - tx 范围后的 gc 候选者：[496:28242122, 496:28242122], [45, 52, 53, 54,...]

因此，根据您的说明，我使用十六进制编辑器（带有十六进制查看器插件的 Notepad++）打开了 db-496.log 文件并查找了 28242122（偏移量），但它不在文件中。我做错了什么？

【讨论】：

你记得在搜索之前将偏移量转换为十六进制吗？