特定の条件下で例外をスローするメッセージ駆動型 Bean があります。例外がスローされると、メッセージは処理されず、キューに戻されます。MQ と WAS (Websphere Application Server) で理解していることから、メッセージは x 回の試行後に不良としてマークされ、キューから削除されるはずです。これは発生せず、メッセージは不良としてマークされたキューに残ります。
MQ および/または WAS の構成のどの部分を正しく設定できませんでしたか?
(MDB が例外をスローする問題は、ここでのポイントではありません)
ありがとう。
キューには属性 BOQNAME と BOQTHRESH があります。これらは、メッセージを再キューイングするバックアウト キューの名前と、メッセージを再キューイングする前のバックアウト数のしきい値に設定する必要があります。
さらに、QMgr はメッセージを指定されたキューに入れることができなければなりません。問題には、キュー名のスペルミス、バックアウト キューがいっぱい、または MDB を実行しているアカウントがバックアウト キューにメッセージを書き込む権限がなかったことが含まれる場合があります。
MDB は、有害なメッセージ ループを検出し、メッセージを再キューイングする場所がない場合、処理を停止します。スレッドは引き続き表示されますが、キューで開いている入力ハンドルが 1 つ以上失われます。この場合、アプリを復活させるには、アプリを再起動する必要があります。
バックアウト先にシステムの DLQ を使用しないでください。DLQ は、宛先キューに解決できない別の QMgr から到着したメッセージを QMgr が配置する場所です。これらにはデッド レター ヘッダーが添付されますが、再キューされた MDB メッセージには添付されません。これにより、DLQ を監視しているオートメーションで問題が発生する可能性があります。したがって、アプリケーションごとに DLQではない例外キューを用意することをお勧めします。
QMgr やチャネルのシャットダウンなどの通常の操作ではバックアウトが発生する可能性があるため、BOQTHRESH は 1 または 2 より大きくする必要があります。私は通常、BOQTHRESH を 5 または 10 に設定しますが、これをもっと高く設定する人を見てきました。再試行に対する許容範囲と、ログ エクステントがいっぱいになるなどの一時的な状態によって通常バックアウトが発生するかどうかによって異なります。
WebSphere が有害なメッセージを処理する方法の記事を参照してください。
これは WAS 5 に適用されますが、原則は変更されていません。