メッセージを空白のサービスバスキューに送信するアプリケーションがあります。 私はまた、このキューからメッセージを読み取り、処理したメッセージをトピックに送信する別のアプリケーションを持っています。
私のメッセージのほとんどがdlqに移行しているのがわかります。紺色のサービスバスエクスプローラで例外が発生すると、すべてのメッセージに対して同じ例外がスローされることがわかります。最大の再試行回数を超えました。メッセージがdlqに移動したため実際の例外を知りたいと思います。
この例外の詳細はどこにありますか？私はこの例外の詳細がどこにでも格納されていると信じていますか？メッセージが死んでいる理由の正確な例外情報
デッドレター作成では10回の配信試行後にメッセージを消費できないと言います。
メッセージがDLQに移動するMaxDeliveryCountを（デフォルト値は10である）、超えている場合。私がコメントで提供した "How do messages get into the DLQ?"を読むと、 "Exceeding MaxDeliveryCount"の下に以下の情報があります。
メッセージがロック（ReceiveMode.PeekLock）で配信されたが、明示的に破棄されたか、またはロックが期限切れになった場合は常に、メッセージのBrokeredMessage.DeliveryCountが増分されます。 DeliveryCountがMaxDeliveryCountを超えると、メッセージがDLQ
に移動しますロック期間をチェックして、あなたのクライアントアプリがロックのタイムアウト間隔内でメッセージを消費することができることを確認してください。また、可能であれば、MaxDeliveryCountに大きな値を設定することもできます。
注：通常、メッセージ配信を保証するために、キューとDLQの両方のメッセージをチェックして処理します。 –
提供された情報をありがとうございます。私は記事を読んだ。しかし、私はまだアプリケーションレベルのデッドレターの例外がキャプチャされているかどうかはわかりません..彼らは本当にキャプチャされているか、アプリケーションが例外をスローしたときに10回再試行してmaxdeliverycount例外をスローします..私はちょうどアプリケーション捕捉されたか否かを判定する。はいの場合、どのようにアクセスできますか？ – Amit
try-catchブロック ' {//処理メッセージ }キャッチ（例外EXPT） {例外EX = EXPTを試みるで例外を捕捉してみてください。 //ログ例外と配信回数 Console.WriteLine（String.Format（ "Message DeliveryCount：{0};例外：{1}"、message.DeliveryCount.ToString（）、ex.Message））; } '' –
あなたがサービスバスExplorerでDLQメッセージの**メッセージカスタムプロパティから ''最大リトライ回数exceeded''見ることを意味していますか？ * DeadLetterErrorDescription *プロパティの詳細な説明はありますか？また、「メッセージはどのようにDLQに入りますか？」（https://github.com/Azure/azure-service-bus/blob/master/samples/DotNet/Microsoft.ServiceBus.Messaging/DeadletterQueue/README）をチェックしてください。 md） " –
また、デッドレター作成をチェックしました。メッセージは10回の配信試行後に消費できないと言われています。しかし、このデッドレターメッセージをデバッグすると、いくつかのマスターデータに起因する例外がスローされます。 .. – Amit
ねえ、フレッド！アプリケーションレベルのデッドレターが発生したときに例外情報を知る必要があります。この情報がどこに取り込まれていますか？これで私を助けることができますか？ – Amit