在下面的场景中，我很好奇发生了什么，因为它与所讨论的队列管理器的活动LOG文件中的内容有关。正在使用线性记录。
MQ Active LOGS在具有100条消息的队列正在使用JMS上下文属性（查找特定消息）进行READ的情况下经历了哪些活动（如果有） - 对于在这个论点的情况下，它永远不会找到。从队列中读取所有消息，但不提交任何消息。因此，消息实际上从未从队列中删除;然而，如果队列管理器在发生这种情况时发生崩溃，那么队列管理器是否会记录此类GET操作以便恢复这些“飞行中”条件？我们最近遇到了这样一种情况：特定队列的出队率在4000-4500 msg / min范围内，而队列深度只有2500左右。我们猜测超过1个这样的进程线程试图读取JMS消息通过上下文（有点像我想的相关ID），但没有任何希望实际找到它正在寻找的消息（由于可能的错误配置）。在此期间，活动的LOGS迅速填满。我们看到的这种肆意排队率是否可能是罪魁祸首？
答案 0 :(得分：1)
MQ在get和put期间写入持久消息的日志记录。更多细节可以在这里找到：
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.dev.doc/q023070_.htm