AzureサービスバスキューのNServiceBus pub-sub

Question

私はAzure Service Busに裏打ちされたNServiceBusを使用して、単純なpub-subデモを実装しようとしています。

私は加入者を作成するたびに、ユニークな名前のEndpointとEndpointInstanceを作成し、そのサブスクライバにサブスクライブします。イベント私は興味があります

加入者がシャットダウンすると、私はイベントから退会し、EndpointInstanceを停止します。

ただし、サービスバスを確認すると、プロセスで作成されたキューおよびトピックのサブスクリプションがクリーンアップされません。これは、しばらくすると、EndpointInstanceの名前を生成する方法のために、何度も使用されない何百ものキューとトピックサブスクリプションが潜在的に存在することを意味します。

どうすればそれらをきれいにできますか？

何か不足していますか？すべての加入者に新しいEndpointとEndpointInstanceを作成してはいけません（これは公式のサンプルとガイドで使用されているパターンのようです）。

UPDATE：

だけ頭に浮かんだの類推は、クライアント（加入者）がオンラインになると、バスに加入プッシュ通知システムのようなものです。イベントが公開されると、私はオンラインクライアントがそれを受け取ることを望みます。クライアントがシャットダウンされると、クライアントがオンラインになったときに失われたメッセージを受け取ることに興味がないので、送信されたメッセージは気にしません。サブスクリプションを閉じて、基盤となるインフラストラクチャ（キュー、サブスクリプションなど）をクリーンアップしたいと考えています。

私のシナリオでは、各クライアントは独自のエンドポイントとエンドポイントインスタンスを定義します。この時点で論理エンドポイントはどのように機能しますか？

Answer 1

パブ/サブデモと、エンドポイントが破棄された後にすべてをクリーンアップする機能があります。エンドポイントを適切に購読解除すると、Azure Service Busからサブスクリプションが削除され、発行されたメッセージはキューにもう到着しません。

生産シナリオでは、エンドポイントをさまざまな理由で停止させることができます。そのうちの1つは、新しいバージョンを導入したり、データストアにメンテナンスを実行したりすることです。もう1つは、サーバー/サービスがクラッシュしたなどの単純なものです。運用シナリオでは、ダウンしている間も、依然としてメッセージがキューに到着したいと考えています。この方法では、エンドポイントが再びバックアップされるたびに確実に処理することができます。

このため、キューのクリーンアップはサポートされていません。エンドポイントを停止した後にすべてをクリーンアップしたい場合は、手動でキューを削除する必要があります。

デモの設定については、固有のエンドポイントとインスタンスがあります。明確さのために、エンドポイントとインスタンスの意味を説明してみましょう。いくつかのタスクを実行する論理的なエンドポイントを構築することができます。これには、さまざまなハンドラ、サガなどが含まれています。固有の名前と固有の機能を持っています。システムには、さまざまな論理エンドポイントを設定できます。

通常は、すべてのエンドポイントに対して1つのインスタンスが存在します。スケールアウトしたい場合は、同じ論理エンドポイントの別のインスタンスを配備できます。Azureサービスバスを使用している場合、competing consumersと呼ばれるものがあります。これは、基本的に、両方のエンドポイントインスタンスが同じキューからメッセージを取得しようとしていることを意味します。 1つは常に勝ち、メッセージの処理を開始します。

メッセージを受け取る（論理的な）エンドポイントのインスタンスを決して特定できないため、同じエンドポイントの別のインスタンスにメッセージを公開することは論理的ではありません。それでも自分のメッセージを購読することはできますが、論理エンドポイントはメッセージを購読します。特定のインスタンスではこれを行わないでください。不可能です。

しかし、は、で、他の論理エンドポイントによって受信されたメッセージを公開することはできます。彼らがどれだけ多くの事例を持っていても。私を困惑今何

---

はあなたの次の文です：

私は加入者の未定数で働いている以上が生み出されているか、既存のものは、様々な条件に応じて、殺されると

新しい論理エンドポイントをオンザフライで作成して展開しているようです。 はであり、配置に基づいて設定に基づいて一意の名前を付けることができます。しかし、私はまだあなたがこれをデモする理由を理解していません。

これが役に立ったら教えてください。そうでない場合は、この投稿の下にコメントしてください。私はさらに質問に答えようとします。おそらくこの投稿の中には、コメントがあなたが使うことができる文字の数に非常に制限されているので、更新として。

Answer 2

あなたが説明したシナリオは意味があります。作成され、目的を果たし、システムから削除される一時的なエンドポイントに興味があります。これらのエンドポイントは一意であり、複数のインスタンスを持たない。たとえそれがあったとしても、すべての事例が明らかにされます。

これは、しばらくすると、私がEndpointInstance名を生成する方法のために再び使用されない何百ものキューおよびトピックサブスクリプションを潜在的に持つことを意味します。

サブスクリプションで発生している問題はバグです。私は問題を提起したhere: link。より多くのフィードバックを提供するためにチャイムしてください。あなたが見たいと思われる動作は、バグが対処されたらがになるはずです。私。特定のイベントの登録を解除すると、そのイベントはエンドポイント（ForwardingTopologyの場合）に転送されなくなり、エンドポイントのサブスクリプション（EndpointOrientedTopologyの場合）の下に保存されなくなります。

エンドポイント入力キューの場合、NSBがエンドポイント自体の実行中にキューを削除する方法はありません。これは、エンドポイントが削除された後にカスタムコードにしなければならないものです。

Answer 3

ここにどのような種類のメンバーがいますか？すべてのクライアントが同じ種類のイベントを受け取るか、またはそれらをフィルタリングする予定ですか？その最後の場合は通知のように。

私はあなたのシステムに少し時間をかけて接続し、このクライアントに特化したイベントにのみ興味があると思っています。

SignalRのようなフレームワークは、特定のクライアントに通知を戻すような用途に適しています。

しかし、システム内では、NServiceBusを使用して独自のエンドポイント間で通信を行うことができます。イベントは、正しいクライアントに通知としてプッシュされる必要があります。