問題タブ [azure-servicebus-topics]

Azure 用に 2 つの Web ジョブを開発しています。1 つはトピックを使用して Service Bus Queue にメッセージを入れ、もう 1 つは同じトピックを使用して ServiceBusTrigger にサブスクライブします。

メッセージはサービス バス キューに正しく送信されますが、ServiceBusTrigger にサブスクライブされた WebJob を実行すると、これらのメッセージは FIFO ベースで処理されません。

メッセージをサービス バス キューに入れる WebJob のコードは次のとおりです。

サービス バス トリガーにサブスクライブされる WebJob には、次のコードがあります。

キューからのメッセージを FIFO として処理するにはどうすればよいですか?

前もって感謝します！

Azure Web ジョブで処理されるトピックとサブスクリプションがありますが、一定回数の再試行の後、一部のメッセージはデッド レター (キューまたはトピック?) に移動する必要があります。デッドレターメッセージを処理するのに何が必要かわかりません。誰かがコード例を持っていますか? これは Azure Web ジョブで可能ですか?

私はほとんどあきらめて、リトライカウンターを使って手動でやっています。当分の間、これは私がやっていることですが、メッセージを同じキューに戻すという考えはあまり好きではありません:

バックグラウンド

クライアント (Web アプリ) から何百万ものメッセージを取得している Azure Service Bus にトピック ( T1 ) があります。3 つの異なるバックグラウンド プロセス (ワーカー ロール) によって作成されたフィルターのない3 つのサブスクリプション ( S1、S2、S3 ) があります。

問題

ワーカー ロールが実行されているとき、最初のサブスクリプション ( S1 ) だけがメッセージをまったく受け取っているように見え、残り ( S2 および S3 ) は何も受信しないか、その一部を取得します。すべてのサブスクライバーは、まったく同じ設定でフィルターなしで同じ方法で作成されます。

Service Bus Explorer はS1 の正しいメッセージ数 (~100K)を表示しますが、S2 と S3 のアクティブなメッセージ数は非常に少ないです ( 10 未満で、通常は 0 )。どういうわけか、クライアントが受信することさえせずにメッセージが削除されているようです。

何が問題で、メッセージ数がサブスクライバー間で一致しない理由を調査する最善の方法は何ですか。何が間違っている可能性があるかについて何か提案はありますか?

ASB トピックにイベントを送信し続けるプロセス (プロセス A) があります。トピックには複数のコンシューマーが存在するため、複数のサブスクリプションがあります。したがって、コンシューマーのプロセスの 1 つがダウンしているとしましょう。これにより、メッセージが消費されないため、トピックがいっぱいになります。これは、ASB トピックにメッセージを完全に送信できないため、プロセス A も失敗することを意味しますか?

コード スニペットを使用して、サービス バス トピックにメッセージを送信しています。

そして実装は

エラー：-

"ErrorCode,12005,Message,""通知の送信中にエラーが発生しました: 操作は割り当てられたタイムアウト 00:01:00 内に完了しませんでした。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。例外の種類と適切な例外処理の詳細については、Exception,""Microsoft.ServiceBus.Messaging.MessagingException: 操作が割り当てられたタイムアウト 00:01:00 内に完了しませんでした。この操作に割り当てられた時間は、より長いタイムアウト。

例外の種類と適切な例外処理の詳細については、

Service Bus で問題が発生しています。

1. 2 つのサブスクリプションを持つトピックがあります。
2. それらに対して重複検出を有効にしました。ウィンドウは 1 分です (最初は 2 秒で試しました)。重複検出を使用して、短い間隔で複数のメッセージが処理されるのを回避しています (メッセージ間の間隔を維持するため)。
3. メッセージ スケジューリング ( ScheduledEnqueueTimeUtc ) を使用して、同じメッセージ ID で 5 分後に表示されるメッセージを繰り返します (新しいメッセージがスケジュールで作成され、古いメッセージが完了するたびに)
4. ワークフローは次のとおりです (問題)。
   • メッセージが初めて公開されたとき (スケジュールなし)
   • このメッセージはすぐにメッセージ ポンプによって消費され、5 分後に表示されることを期待して、同じ詳細と 5 分のスケジュール時刻を持つ新しいメッセージがトピック (UTC) に送信されます。
   • メッセージがサブスクリプションに表示されない
5. デバッグすると、この問題は発生しません
6. 少なくとも 30 秒の遅延 (予定) で最初のメッセージを送信すると、正常に動作しています
7. 重複検出をオフにしてトピックとサブスクリプションを再作成すると、上記のワークフローを使用してメッセージを取得できます

公開されたメッセージに何が起こっているのか手がかりがないため、問題の根本原因を特定するための支援が必要です.

この記事 ( https://azure.microsoft.com/en ...) によると、Service Bus はキュー/トピックごとに 1 秒あたり最大 2000 メッセージを処理できます。この記事: https://azure.microsoft.com/en... 「これは、分割されたキューまたはトピックの全体的なスループットが、単一のメッセージ ブローカーまたはメッセージング ストアのパフォーマンスによって制限されなくなったことを意味します。」分割されたキュー/トピックを作成すると、内部で 16 個のパーティションが作成されると思います。私の質問は次のとおりです。分割されたキュー/トピックのスループットは、16 x 2000 = 32,000 (概算) まで直線的に上昇しますか? または、2000 msg/秒のスループットが維持されますか。分割されたキュー/トピックのスループット ベンチマークを教えてください。現在、非常に高いスループットのトピックを必要とするシナリオを分析しています。この質問に関するガイダンスは本当に役に立ちます。

この質問は、次の Azure サイトにも投稿されています: https://azure.microsoft.com/en-us/documentation/articles/service-bus-performance-improvements/

私はトピック/サブスクリプション サービスの設定に取り組んでおり、SQLFilter の構文について助けが必要です。これにより、BrokeredMessage プロパティ、特に To プロパティにアクセスできるようになります。メッセージのシステム プロパティにアクセスするための SQL フィルタの正しい構文は何ですか?

このチュートリアルを使用して、必要に応じてトピック/サブスクリプションに送受信できる実際の例があります: https://azure.microsoft.com/en-us/documentation/articles/service-bus-queues-topics-subscriptions/

ただし、今は BrokeredMessage の To プロパティに基づいて、サブスクリプションごとに SQL フィルターをセットアップしたいと考えています。私が従ったチュートリアルでは、「サブスクリプションが作成されると、システム プロパティ (ラベルなど) とカスタム アプリケーション プロパティ (StoreName など) の両方のメッセージのプロパティで動作するフィルター式を指定できます。 .)"

StoreName などのカスタム プロパティを設定すると、次のようになります。

次のような SQL フィルターを使用してサブスクリプションを設定します。

サブスクリプションは期待どおりにフィルター処理されます。しかし、この記事で説明されているように BrokeredMessage オブジェクトの To プロパティ (またはラベル) を使用しようとしても、うまく機能しませんでした。次の SQL フィルターを試してみましたが、うまくいきませんでした。メッセージのシステム プロパティにアクセスするための正しい構文は何ですか?