原因となっている問題 (データベースがダウンしている、十分なスペースがないなど) を解決した後、管理者が (GUI または任意のツールを介して) メッセージを再送信し、デッド メッセージ キューまたはデッド レター キューに保存できる JMS ブローカがあるかどうか疑問に思います。 ）。
WebSphere はデッド レター キューに保存されたメッセージを再送信する機能を提供します
。
他の JMS ブローカーのオプションは何ですか? または、メッセージに依存している場合は、DMQ/DLQ 機能を使用しないのが最善の方法ですか?
どうもありがとう
WebSphere MQについては答えることができますが、他のJMSプロバイダーについては答えることができません。WMQの場合、QFULLなどの一時的なエラーに対してDLQメッセージを自動的に再試行できるDead Letter Handler（DLH）を含むいくつかのツールがあります。たとえば、キューがいっぱいになり、受信メッセージがDLQにオーバーフローします。DLHはこれらのメッセージの再試行を開始し、キューが空になると、元のターゲットキューのメッセージを自動的に置き換えます。他のツールはWMQSupportPacsとして利用できます。
一般的な経験則では、毒メッセージを処理するための何らかのプロセスが必要です。システムDLQは共有されているため、理想的にはこれはアプリケーション固有の例外キューになります。複数のアプリがDLQにメッセージをこぼし、そのうちの1つのアプリのサポートチームがメッセージだけでなくキュー全体をクリアしたケースを何度も目にしました。良くない。
もう1つの注意点は、DLQにメッセージが届くと、通常、メッセージシーケンスが中断されることです。たとえば、キューがいっぱいになり、メッセージがDLQに送信されます。キューが空になると、メッセージはDLQから再生され、その時点で、メッセージが到着すると新しいメッセージが散在します。理想的には、アプリはメッセージシーケンスの問題に敏感ではなく、各メッセージはアトミックです。これがあなたの最後の質問に答えるための鍵です。DLQを使用するかどうかは、アプリがメッセージの順序付けに敏感であるかどうかに大きく依存します（少なくともWMQでは）。順序付けが問題になる場合は、メッセージをセカンダリキューに波及させて、新しいメッセージがまだ到着している間にそれらを再生するオプションはありません。その場合は、キューをいっぱいにしてスロットルバックするか、送信アプリをシャットダウンすることをお勧めします。
DLHの詳細については、http：//bit.ly/aYJ13qを参照してください。
WMQ SupportPacsはここにあります：http：//bit.ly/bdSUfd （ MA01とMO01をチェックしてください）