AMQ 5.7 在這里。我繼承了一組非常古老的 Java 應(yīng)用程序，它們使用 ActiveMQ (AMQ) 代理在彼此之間以及與該生態(tài)系統(tǒng)之外的客戶端進行通信。因此，AMQ 代理上有數(shù)百個 (!!!) 隊列，并且實際上有數(shù)百個JMS 客戶端生活在數(shù)十個不同的服務(wù)器上（每個）向這些隊列發(fā)布消息和從這些隊列消費消息。它是一個老鼠窩。我有一個隊列，我們稱之為shouldBeDead，它不應(yīng)該再接收任何消息。它在某個時間點已被棄用，并且不應(yīng)再向該隊列發(fā)送消息。但是定期它被數(shù)百消息從轟炸東西/某處。它沒有消費者（這是正確的；我的 Java 應(yīng)用程序套件不再在它們的代碼中的任何地方使用它，因此沒有任何東西在監(jiān)聽該隊列以消耗它的消息）。更復(fù)雜的是，這是一個舊的 AMQ 版本，存在這個已知的 UI 錯誤，其中TLDR；是：我需要將 AMQ 實例升級到 > 5.12.x。但是，由于這個問題上下文之外的原因，我目前無法升級 AMQ。因此，雖然我希望瀏覽排隊的消息shouldBeDead并深入了解它們以獲取有關(guān)它們的信息，但我什至無法在 AMQ Web UI 或應(yīng)用程序日志中查看它們。我只是想弄清楚這些消息是從哪里來的！進行網(wǎng)絡(luò)分析可能很有成效，但超出了我的技能范圍，這些消息看似隨機地涌入隊列，沒有任何可辨別的模式。我希望我可以使用一些 AMQ 命令行功能來檢查隊列元數(shù)據(jù)，也許可以查看 KahaDB 或任何其他類型的魔法來查看這些消息和/或從中獲取跟蹤/客戶端信息.最壞的情況我知道我可以部署一些代碼更改以重新添加shouldBeDead偵聽器/消費者并記錄消息，但是我真的試圖在不進行任何代碼更改的情況下執(zhí)行此操作。任何想法/想法？提前致謝！