c# - Azure サービス バス キュー PeekBatch ロック?

Question

(Windows Azure Service Bus パッケージ バージョン 2.1.2.0) でPeekBatch(<messageCount>)メソッドを使用しています。QueueClient

最初は問題なく動作し、キューに存在する単一のメッセージを返しますが、その後の呼び出しでは何も返されません。5 分後、通話は再びメッセージを返します。

の最大ロック時間は 5 分なので、私が知る限り、ピーキングはロックされるべきではありませんが、受信のようにこれらのメッセージを実際にロックする BrokeredMessageかどうか疑問に思っています。PeekBatch

実際にキューに何があるかを確認できるように MVC ビューを構築しようとしていますが、これが邪魔になっています。誰でもこれに関するガイダンスを提供できますか?

更新QueueClient:これは、静的プロパティを使用してキャッシュした場合にのみ発生しているようです。QueueClient毎回新鮮なものを作成すると、PeekBatch期待どおりに機能します。なぜ再利用するQueueClientとこれが発生するのか、まだわかりません。 マイクロソフトはQueueClient毎回再作成するのではなく、再利用することを推奨しているようですので、私はまだここで途方に暮れています.

Answer 1

QueueClient は多少役に立ちます。Peek メソッド (Peek および PeekBatch) では、単純に呼び出すことができます。または、特定のシーケンス番号を指定して、特定のシーケンス番号の後に特定のメッセージを取得することもできます。シーケンス番号なしで単に Peek を呼び出すか、この場合は PeekBatch を呼び出すと、キュー内の最初のメッセージが取得されます。メッセージが返されると、QueueClient はプルした最後のシーケンス番号を追跡します。後続の Peek の呼び出しごとに、キュー内の次のメッセージがフェッチされます。メッセージを「参照」していて、毎回キューの最初のメッセージに関心があるだけではないという考えです。

したがって、ループ状態で、メッセージが返されなくなるまで peek を繰り返し呼び出すと、基本的にキュー内のすべてのメッセージを参照したことになります。

シーケンス番号なしで PeekBatch を呼び出しているため、QueueClient は最後に取得したセットを記憶しているため、次の呼び出しは実際には、参照した最後のメッセージの後に次のセットを取得しようとします。これが、QueueClient を再作成するとリセットされたように見える理由です。5 分後に自然にリセットされたように見える理由は奇妙に思えますが、キューの Timeout 操作に関連するある時点の後にブラウジング値を消去するだけかもしれません。それまでに、それがビジー キューである場合、シーケンス番号はとにかくかなり離れています。

本当に最初のメッセージだけを見る必要がある場合は、peek を 1 回だけ呼び出します。最初のメッセージのみを返します。毎回最初のメッセージを継続的にプルする必要がある場合は、Peek(0) を実行します。最初に毎回 10 件のメッセージが必要な場合は、PeekBatch(0, 10); を呼び出します。これは、シーケンス番号が 0 より大きい最初の 10 個のメッセージを教えてくださいと言っているようなものです。

QueueClient を再利用するためのガイダンスは適切です。情報や物事のあらゆる種類のキャッシュを行っています。毎回再作成する必要はありません。