IBM MQ Connector のトラブルシューティング - Mule 4

場合によって、アプリケーションが失敗した理由が不明で、アプリケーションの MQ サーバーとのインタラクションで何が起こっているかについて理解を深める必要があることもあります。

詳細なログを収集する手順は、次のとおりです。

メッセージの肯定応答に関してアプリケーションの設定に矛盾が生じる理由はいくつか考えられます。 アプリケーションのセッション肯定応答は次のように設定できます。

セッション肯定応答を ​IMMEDIATE​ に設定すると、メッセージは受信されると直ちに肯定応答されます。​IMMEDIATE​ 肯定応答を ​Ack​ または ​Recovery session​ 操作と組み合わせないでください。

セッション肯定応答を ​AUTO​ に設定すると、イベントが完了したときに ​On New Message​ ソースで肯定応答が制御されるか、イベントの処理中にエラーが発生した場合はセッションが回復します。​AUTO​ 肯定応答のアプリケーションで手動肯定応答またはセッション回復を追加すると、チャネルで操作が重複します。

セッション肯定応答を ​MANUAL​ または ​DUPS_OK​ に設定する場合は、フロー実行のすべてのパスでメッセージ肯定応答またはセッション回復を取得することを確認してください。確認しなかった場合、メッセージがリークし、作業単位の最大深度に達したときにコンシューマーが無応答になる可能性があります。

この問題を解決する手順は、次のとおりです。

フローデザインを詳しく調べて、すべてのメッセージが肯定応答されるか、セッションが回復することを確認してください。

通常、MQ の停止したコンシュームメッセージは肯定応答されていない大量のメッセージに関連しています。Mule アプリケーションに ​On New Message​ ソースまたは ​Consume​ 操作とメッセージの手動肯定応答があり、メッセージのすべてのパスに適切な肯定応答またはセッション回復設定があるわけではない場合、Mule アプリケーションでコンシューマーが無応答になる場合があります。

このエラーを解決する手順は、次のとおりです。

ブローカー側で肯定応答されていないメッセージの深度をチェックし、アプリケーションロジックを確認します。

接続にバインディングモードを使用している場合、ドライバーは JNI リソースを読み込みます。JNI リソースは一度しか読み込めないため、アプリケーションを再デプロイすると、エラーがスローされます。

このエラーを解決する手順は、次のとおりです。

ドメインレベルでドライバー連動関係を追加します。これにより、アプリケーションの再デプロイメントが可能になります。

次に、一般的なスローメッセージとその解釈方法のリストを示します。