5

.NET 4 で記述された Windows サービスがあり、無限に実行される while(running) ループを含む複数のスレッドを作成します。サービスを停止すると、実行中のブール値が false になり、while ループから抜け出し、各スレッドが停止すると、サービスは最終的に停止します。

その間、oMessageReceiver.Receive(TimeSpan.FromSeconds(30)) を呼び出します。そのため、サービスを停止しようとすると、Receive() プロセスがタイムアウトするまで最大 30 秒待たなければならないことがあります。

1 つのオプションは、タイムアウトを 30 秒からそれより短い時間に短縮することです。どのようなパフォーマンス上のペナルティが発生するかはわかりませんが、プロセスは BrokeredMessage なしでは機能しないため、リスナーを可能な限り頻繁に、かつ長く開いたままにしたいと考えています。

MessageReceiver に .BeginReceive() メソッドがあることがわかります。受信がタイムアウトするのを待っている間にサービスがハングするのを防ぐために、ここで使用できるプログラミング パターンがあると思います。無限に実行中の Windows サービスで APM の Begin/End 関数を使用する方法を説明できる人はいますか?

4

2 に答える 2

4

新しい 2.1 Windows Azure SDK では、最近 2.0 SDK で導入された OnMessage を使用するように Service Bus Worker Role テンプレートを変更しました。そのテンプレートをのぞいて、開始するために使用するコードを確認できます。このアプローチでは、メッセージが到着したときに実行するアクションを設定します。実際、追加のスレッドを処理する設定時に、 OnMessageOptionsに MaxConcurrentCalls プロパティを設定することもできます。OnMessage アプローチを使用した場合は、サービスが QueueClient を閉じてそれ以上処理されないようにする同様のことを行います。また、いずれかのスレッドでメッセージが処理されているかどうかを同期インジケーターで追跡し、その処理のみが完了するのを待つこともできます。

非同期メソッド (Begin/End) を使用する最良の方法については、いくつかの例が含まれている「Windows Azure Service Bus Brokered Messaging を活用するためのベスト プラクティス」を参照してください。

于 2013-08-18T17:08:48.977 に答える
2

MessageReceiver が作成された MessageFactory を閉じて、受信操作をキャンセルします。メッセージ ファクトリを閉じる前に MessageReceiver で Abort または Close を呼び出すと、同じ問題が発生しました。

非同期の Begin/End を使用しても違いはありません。補足として、非同期で実行する場合は、TaskFactory.FromAsyncを使用してタスク ラッパーを作成し、新しい async-await 機能を利用することを検討してください。

同じ問題に関するこの質問に対する私の回答も参照してください。

長時間実行されている Azure Service Bus QueueClient の受信をキャンセルしますか?

于 2013-08-19T19:21:39.423 に答える