問題タブ [nservicebus-distributor]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
nservicebus-distributor - クラスター化された DB を使用する NService Bus ディストリビューター
現在、ディストリビューターで NService バスを使用していますが、クラスター化された MSMQ に移行せずに HA にしたいと考えています。クラスター化された SQL サーバーが既にあります。NService bus Distributor に MSMQ の代わりに DB を使用させる方法はありますか?
nservicebus - NServiceBus ディストリビューターはワーカーから進捗状況を報告できますか?
NServiceBus を調査していますが、このシナリオを処理するために NServiceBus をどのように使用できるか (または使用できるかどうか) がわかりません。
複数のクライアントが作業要求を送信しており、ディストリビューターはそれをワーカーにファームアウトしています。作業が完了するまでに時間がかかるため、最初のリクエストを送信したクライアントに作業者に進捗状況を報告してもらいたい.
全二重サンプルと、そのサンプルにディストリビューターを追加する方法も確認しました。これらは機能していますが、一連の進行状況メッセージで応答するように変更すると (以下に示すコードのように、メッセージ間に遅延があります)、クライアントはすべての進行状況メッセージを同時に受け取ります。
NServiceBus がどのように機能するかについて、基本的なことを理解していないのではないかと思います。誰かが私が間違っている場所を説明したり、いくつかの例やドキュメントを教えてくれませんか?
nservicebus - NServiceBus: NSB ディストリビューターはボトルネックですか?
ネットワーク ロード バランサーを使用してメッセージを分散したかったのですが、Transactional キューを使用しようとすると問題が発生することがわかりました。現在、NSBディストリビューターを使用する予定です。ディストリビューターのホストがボトルネックになることはありませんか? すべてのサブスクライバー インスタンスを 1 台のマシンのボトルネックの背後に置くため、ディストリビューターはサブスクライバーをスケール アウトするという目的を無効にしていると私は考えていました。考え?
nservicebus - NServiceBus Pub/Sub の例と「ディストリビューター」
NServiceBus の Pub/Sub の例を確認しました。
私は今、NServiceBusの「ディストリビューター」の概念に頭を悩ませようとしています。
「ディストリビューター」にマッピングされた例の一部があると思ったので、最初は非常に混乱しました。そうではない、と今は思い始めています。
したがって、この例は 2 つの可動部分を示しています。パブリッシャーとサブスクライバー。しかし、次のページには、少なくとも 4 つの可動部分が示されています。
- サブスクリプション データベース
- パブリッシャー ノード (P_1、P_2)
- 卸売業者
- サブスクライバー ノード (S_A_#、S_B_#)
ここにたどり着くまでは、すべて意味がありました。今、私はこれらの新しいプレーヤーがどのように素晴らしい明確な例にマッピングされるのか疑問に思っています. (または、私が見るべき新しい例はありますか?)
これらについてのページを読みましたが、概念的な観点からはすべて理にかなっています。しかし、それが実際の生活/コード/例でどのように機能するかわかりません。
私の質問が漠然としすぎている場合は、より具体的な質問をさせてください:上記の 4 つの部分を使用するには、Pub/Sub の例に何をする必要がありますか?
deployment - NServiceBusのメッセージタイプごとに1つのディストリビューターのベストプラクティスの背後にある理由は何ですか?
メッセージタイプごとに1つのディストリビュータープロセスを構成する必要があるというベストプラクティスとして何度か言及されていますが、その理由についての説明はありません。ディストリビューターの数を増やすと展開が複雑になるので、その背後にある理由を知りたいと思います。私の推測では、特定のメッセージタイプで利用可能なすべてのサブスクライバーがビジー状態の場合、ディストリビューターは1つが解放されるのを待ってスタックし、無料のサブスクライバーを持つ可能性のある他のタイプのメッセージはディストリビューターのワークキューに積み上げられます。これは正確ですか?他の理由はありますか?
nservicebus - NServiceBus:PubSubがディストリビューターと連携する際の問題
NServiceBus 2.5を使用しており、ディストリビューターと連携してNServiceBusPubSubサンプルの簡略化されたバージョンを取得しようとしています。簡略化:
- 1パブリッシャー
- 卸売業者
- 1サブスクライバーこれらすべてが1台のマシン上にあります。
単一のディストリビューターの背後にある複数のサブスクライバー、複数のマシンなど、より複雑なものに移る前に、これを機能させたいと思います。
最初に、ディストリビューターなしで動作する単純化されたpub subの例を取得しました(つまり、1つのpubと1つのsub-そしてそれは正常に動作しました)。
私が理解しているように、それが機能する方法は次のとおりです。ディストリビューターは独自の制御キューとデータキューを定義します。パブリッシャーには制御キューがありますが、他の構成がこのキューを参照していません。パブリッシャーは、配布データキューを参照します。サブスクライバーは、ディストリビューターのデータと制御キューを参照します。
簡略化されたpub-subディストリビューターをこの構成で動作させることができませんでした。パブリッシャーのデバッグをいくつか実行しましたが、パブリッシャーのBus.Publishで、公開するサブスクライバーが見つかりませんでした。
私が間違っていることと、これを機能させるために何をする必要があるかについてのアイデアはありますか?
それぞれの構成は次のとおりです。
出版社:
卸売業者
サブスクライバー
publish-subscribe - NServiceBus:パブリッシャーおよびサブスクライバーとは異なるマシン上のディストリビューターを持つPubSub
真ん中のディストリビューターで動作するPubSubサンプルがあります-それらはすべて私のローカルマシン上にあります。現在、ディストリビューターを別のマシンに移動しようとしていますが、問題が発生しています。サブスクライバーはディストリビューターを介してパブリッシャーに登録されているようです(サブスクライバーの数を示し、適切な値を提供するログステートメントをパブリッシャーに追加しました)が、サブスクライバーはいずれも取得しません公開されたイベント。私は何が間違っているのですか?さまざまなキューに提供する必要のある権限はありますか?これが私の設定ファイルです:
出版社:
サブスクライバー:
ディストリビューター:
上記の構成では、ディストリビューターは「rosmi」というマシンで実行されており、パブリッシャーとサブスクライバーは「rrajagop」で実行されています。
nservicebus - NServiceBus メッセージを特定のクライアントにルーティングする最良の方法は何ですか?
ClientRequestMessage
特定の のリクエストを含むメッセージがあるとしますClient
。Web アプリケーションはこれらの要求を生成し、Client
処理のために正しいものに送信する必要があります。これにはいくつかのオプションを考えることができます。
- すべてのメッセージが送信される単一のキューを作成し、特定のクライアント ハンドラーがプロパティ ( など
ClientId
) をチェックして、それが重要かどうかを判断することができます。しかし、これは私にとって多くのレベルで間違っていると感じています。 - 私はすべてのクライアントにメッセージを公開し、彼らは処理中にそれを気にするかどうかを決定できます. これはトラフィックが多すぎるように思われ、そもそも気にする必要のないメッセージを処理するために各クライアントの時間を無駄にします。
- これらのメッセージもルーティングされるクライアント固有のキューを持つことができます。これは私にとって最高の気分ですが、どうすればよいかわかりません。シンプルに保ち、クライアント固有のメッセージ タイプを避けたいのですが、NServiceBus に「クライアント A の場合はクライアント A のキューに送信し、クライアント B の場合はクライアント B のキューに送信します」と伝える方法がわかりません。
だから私の質問は、これを設定するための最良の(最も効率的?最も管理しやすい?)方法は何ですか?ディストリビューターを使用する必要があると確信していますが、肯定的ではないので、尋ねてみようと思いました。
おまけの質問:
各クライアントに複数のハンドラーがあるとします。そのうちの 1 つだけが特定のメッセージを処理するようにするにはどうすればよいですか? クライアントごとにディストリビューターが必要ですか?
soa - フェールオーバー クラスターで nServiceBus を使用する方法
サービス (サブスクライバー) にメッセージを発行するフロントエンドがある開発環境で nServiceBus を使用しています。人生は素晴らしい。
FrontendWebServer -> MiddlewareServer
運用環境では、フェールオーバー用に 2 つのフロントエンド サーバーと 2 つのミドルウェア サーバーを実行します。
FrontendWebServer -> LoadBalancer(F5) -> MiddlewareServer
FrontendWebServer -> LoadBalancer(F5) -> MiddlewareServer
これは URL に対してはうまく機能しますが、MSMQ にはマシン名を使用する必要があるため、行き詰まります。
各フロントエンド構成で物理的なミドルウェア マシン名を指定したくありません (構成の管理が難しくなり、1 つのミドルウェア サーバーがダウンすると、その特定のフロントエンドへのメッセージも停止するため)。
nServiceBus ディストリビューター (各フロントエンドにインストール) を使用しようとしましたが、サブスクライバーは 1 つのディストリビューターしかリッスンできないようです。
別の構成を使用せずにこの問題を回避する方法はありますか?
nservicebus - NServiceBusディストリビューター:クライアントの再起動後のStorageQueueへの余分なエントリの防止
簡単にするために、ディストリビューターのControlInputQueueとそのStorageQueueの両方を同じものと呼びます。ディストリビューターのクライアントがControlInputQueueにエントリを書き込んでその可用性を通知する方法と、ディストリビューターがエントリをStorageQueueに移動して、どのクライアントが作業に使用できるかを追跡する方法を理解しています。それらを同じものとして扱うと、説明が簡単になります。それで...
NServiceBusディストリビューターの動作を実証するための概念実証を作成しました。予想どおり、クライアントが起動すると、ディストリビューターのStorageQueueにエントリが追加されます。メッセージが(InputQueueを介して)ディストリビューターに着信すると、ディストリビューターはStorageQueueからエントリを削除し、指定されたクライアントにメッセージを転送します。クライアントはその作業を実行してから、ディストリビューターのStorageQueueにエントリを追加し直します。したがって、ディストリビューターのStorageQueueには最大で1つのエントリ(クライアントごと)があります。
私の問題は、クライアントが手動または予期せずにシャットダウンされたときに発生します(サーバーが爆発するなど)。クライアントのエントリは、ディストリビューターのStorageQueueに引き続き存在します。ディストリビューターが知る限り、そのクライアントは引き続き使用可能です。これは問題ありませんが、クライアントが再度起動すると、StorageQueueに別のエントリが追加されます。したがって、1つのクライアントのStorageQueueに2つのエントリがあります。
ディストリビューターが特定のクライアントに対して1つのStorageQueueエントリのみを持つようにする方法はありますか?