次のシナリオでは、問題のキュー マネージャーのアクティブな LOG ファイルの内容に関連して何が起こるか興味があります。線形ロギングが使用されています。
たとえば 100 個のメッセージを含むキューが JMS コンテキスト属性を使用して読み取られている (特定のメッセージを探している) シナリオ中に、MQ アクティブ LOGS によってどのようなアクティビティが発生したか (ある場合) -- この場合、議論、それは決して見つけられません。すべてのメッセージがキューから読み取られますが、コミットされるメッセージはありません。したがって、メッセージがキューから実際に削除されることはありません。ただし、キュー マネージャーは、これらの「実行中」の状態を回復するために、そのような GET 操作を記録しますか? これが発生している間にキュー マネージャーがクラッシュした場合はどうなりますか? 最近、特定のキューからのデキュー レートが 4000 ~ 4500 メッセージ/分の範囲であるのに対し、キューの深さは約 2500 であるという状況を経験しました。複数のそのようなプロセス スレッドがコンテキストによって JMS メッセージを読み取ろうとしていたと推測されます (相関 ID のようなものだと思います)。 )。この間、アクティブな LOGS は急速にいっぱいになりました。私たちが見たような不当なデキュー率が原因である可能性はありますか?