Azureサービスバスのキューメッセージの処理

Question

私は内部的にホストされているAPIを呼び出すキュートリガーとして機能する青空関数を持っています。

有毒ではないという問題のために処理できなかったメッセージを処理する方法については、オンラインで確定的な回答はないようです。

例：

メッセージが受信され、関数がAPIを呼び出しようとします。メッセージのペイロードは正確で、API /サービスは何らかの理由でダウンします（この時間は10分以上かかる可能性があります）。現在の状況は、メッセージの配信数が最大（10）に達してからデッドレターキューにプッシュされ、その後、各メッセージの後に発生します。

配信数を増やしたり、最大に達するとリセットする方法が必要です。あるいは、API /サービスがバックアップされて実行されるまで、キュー上のメッセージの処理を停止したいので、配信カウントをインクリメントせずにメッセージのピークロックを放棄することもできます。 このようにして、サービス間の接続の問題のために、処理できるすべてのメッセージがデッドレターになるようにします。

これを達成するためのアイデアはありますか？

Answer 1

現在のところ、メッセージの配信数が最大（10）に達してから、デッドレターキューにプッシュされると、それ以降の各メッセージで発生します。 MaxDeliveryCount超えるについてこのdocument状態として

：

キューとサブスクリプションがQueueDescription.MaxDeliveryCount/SubscriptionDescription.MaxDeliveryCountの設定を持っているが、 デフォルト値は10です。メッセージがロック（ReceiveMode.PeekLock）で配信されたが、明示的に破棄されたか、またはロックが期限切れになった場合は常に、メッセージのBrokeredMessage.DeliveryCountが増分されます。 DeliveryCountがMaxDeliveryCountを超えると、メッセージはDLDに移され、 `` MaxDeliveryCountExceeded```理由コードが指定されます。

この現象は無効にできませんが、MaxDeliveryCountは非常に大きな数値のに設定されます。

• ReceiveMode.PeekLock

  下のメッセージを受信するためにあなたが最大配信数のを指定することができます。あなたの条件によると、私はあなたがあなたの目的を達成するために、以下のアプローチをたどることができることを前提と

Azure Portal上のサービスバスキューの「設定>プロパティ」の下の1〜2147483647の間で設定します。あなたのAPI /サービスがダウンしたときは、例外をtry-catchできReceiveMode.ReceiveAndDelete

下のメッセージを受信するために、あなたはあなたのキューにメッセージを再送信することができ

。