問題タブ [nservicebus-distributor]

NServiceBus Distributor/Worker パターンは、ローカル入力キューの厳しい要件により、MSMQ にとって完全に理にかなっています。

しかし、これはRabbitMQには当てはまりません.NServiceBusディストリビューターがRabbitMQにどのように関連するかを理解しようとしています. RabbitMQ を使用すると、複数のワーカーが同じリモート キューから読み取ることができます。

実際のシナリオは、AWS Auto Scaling グループを使用して、可用性の高い RabbitMQ クラスターを指すワーカーをスケールアウトするのと似ています。ディストリビューターを完全に回避することで、セットアップの構築、テスト、およびプロビジョニングがはるかに簡単になります。

考え？

（分散シナリオで）ワーカーが失敗した（メッセージが処理されていない）をディストリビューターのソースキューに返すように構成して、別のことをすることは可能ですか？ワーカーはこのメッセージを処理しようとしますか?

別々のマシンで実行する NServiceBus ディストリビューターとワーカーを作成しました。ワーカーを実行すると、ディストリビューターにメッセージが正常に送信されます (ストレージ キューを介して処理されていることを確認できます) が、何らかの理由で、呼び出されたディストリビューターで出力キューが作成されます。

'DIRECT=TCP:xx.xx.xx.xx\PRIVATE$\order_queue$ (キューを 'DIRECT=OS:WORKERDNSNAME\private$\myqueue' と呼ぶ必要がある場合)。

order_queue$ が作成されている理由を知っている人はいますか?

他の 3 つのワーカー エンドポイントを持つディストリビューターとして機能するエンドポイントがあります。受信したメッセージの処理エンドポイントは、トランザクションを開き、一部の xml データを SQL データベースにインポートしようとします。このプロセス中に何らかの例外がスローされた場合、例外がキャッチされ、トランザクションがロールバックされ、xml データがエラー フォルダーに書き込まれます。単純化すると、次のようになります。

そもそも、トランザクションのロールバック後に再試行は行われません。しかし、メッセージが再度送信されると、すべてのワーカー エンドポイント (ワーカーのみ) で例外が発生し (トランザクションを登録できず、メッセージをコントロール キューに送信できませんでした --> 以下のスタック トレースを参照)、nservicebus はメッセージを再試行します (これにより、エラーフォルダにファイルが複数回出現する場合) 分散トランザクションが無効な状態のようです。例外を引き渡す (例外を再スローする) ことができるので、nservicebus がロールバックを処理しますが、その場合、ファイルはエラー フォルダーにも数回書き込まれます (再試行メカニズムのため)。

• NServicebus バージョン: 4.6.0.0
• キューイング: MSMQ

分散システムにメッセージを送信する作業を行っています。したがって、ゲートウェイを使用することを好みます。問題は、Sitekeys、アドレス、channelType 情報を動的に取得していることです。Nservicebus は、app.config 内のサイトキーと対応するアドレスをチェックします。しかし、私の app.config には何もありません。app.config をコードから動的に変更したかったのです。これは正しいアプローチですか？または、これを行う方法はあります。

以下はコードです。

App.config

コード