問題タブ [nservicebus4]

ドキュメント管理システムへのドキュメントの保存を処理する NServiceBus エンドポイントがあります。ドキュメントを保存したら、 を呼び出しますBus.Reply(new DocumentSaved{})。

これSaveDocumentは、Saga (応答を深く気にする) から送信する場合は正常に機能しますが、Web クライアント エンドポイント (つまり、応答をまったく気にしない MVC プロジェクト) から送信する場合は失敗します。失敗は、Web クライアント エンドポイントに応答を処理するためのキューがないためです。

ここで何が間違っていますか？(MVC プロジェクトが処理されることのない一連の応答を保持するためにキューを作成する必要はありません。)

アプリケーションを NServiceBus 4 から 5 にアップグレード中です。

実装するクラスがIWantToRunWhenBusStartsAndStopsあり、Start()メソッドで EndpointName を出力します-から取得しますNServiceBus.Configure.EndpointName

NServiceBus 5 では非推奨であり、正しく実行したいと考えています。EndpointName を取得するにはどうすればよいですか?

この質問は、saga データが Azure Table Storage に永続化されている場合の、saga データへの同時アクセスに関するものです。また、Particular のドキュメントにある情報も参照しています: http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency

ハンドラーを同時に実行している 1 つのサガ内で、サガ データへの変更は、"azure テーブル ストレージに変更をポストする最後の変更が優先される" シナリオで動作しているように見えることに気付きました。NSB を Azure Table Storage と組み合わせて Saga データの永続化レイヤーとして使用する場合、これは意図された動作ですか?

例：

1. Saga Data の整数プロパティ、現在 = 5 と仮定
2. このサガでは、5 つのコマンドが同じハンドラーの 5 つのインスタンスによって処理されます
3. 各コマンド ハンドラーは、サガ データの整数プロパティをデクリメントします。
4. サガ データの整数プロパティの最終値は、これらの 5 つのメッセージを処理した後、実際には 4 になる可能性があります。各メッセージがサガの新しいインスタンスによって処理された場合、異なるサーバー上にある可能性があり、それぞれが整数プロパティが 5 であることを示すサガ データのコピーを持っています。 、それを 4 にデクリメントし、ポスト バックアップします。今説明したのは非常に同時実行の例ですが、5 つのメッセージのいずれかが同時に処理された場合、整数が 0 より大きくなる可能性があります。サガ データの整数プロパティが 0 に達するのは、5 つのコマンドがたまたま実行されたときだけです。連続して。

また、Azure Table Storage は Optimistic Concurrency をサポートしているため、Raven を永続化テクノロジとして使用する場合に RavenDB で有効にするのと同じように、Table Storage でこの機能を使用できるようにすることは可能ですか?

これが不可能な場合、これを処理するための推奨されるアプローチは何ですか? 現在、複数のメッセージを同時に処理する可能性のある saga 内のハンドラーは、saga データを変更できないというパラダイムにサブスクライブしています。つまり、saga メッセージの調整は、saga データを使用するのではなく、saga の外部の手段を介して行われます。当初の意図どおりです。

これは問題ではありませんが、NserviceBus で発生する「魔法」を理解するための質問です。

NServiceBus-Service がそのように呼び出される作業環境があります。

同じディレクトリ内に、私のアプリケーション「My.Adapter.dll」があり、これにも構成があります。どこにも NserviceBus.config はありません。まだ: NserviceBus は、「My.Adapter.dll」を使用する必要があることを認識しているようです。

なぜNServiceBusはそれを知っているのですか? キュー (MSMQ) やアプリケーションへの参照が見つかりませんでした。レジストリに保存されていますか？はいの場合: どこですか?

SQL Server トランスポート (2012) で NServiceBus 4.6 を使用しています。SQL Server データベースは、可用性グループを使用して高可用性を実現するように設定されています。

^{当社の DBA は、トランスポート データベースで発生している「チャーン」の}量、特にこれが WAN に及ぼす負荷について不満を漏らしています。

私たちは現在 XML シリアライゼーションを使用しているので、利用可能な他のシリアライゼーション オプションを調べ始めました (まだ判読できるように、おそらく JSON を好むでしょう)。しかし、これを調べ始めると、メッセージ本文は通常 600 ～ 1000 バイトであるのに対し、メッセージ ヘッダーは通常 1200 ～ 1800 バイトの範囲であることがわかりました¹。そのため、ボディサイズに関して大幅な節約を達成したとしても、私が探している大規模な改善は実現しません.

質問

私が理解しているように、メッセージが SQL Server データベースに保存されているときにヘッダーを読み取る必要がないことを考えると、メッセージを圧縮する方法はありますか?

または、このデータベースに追加および削除するデータの量を減らすための他の戦略はありますか? (現時点では NSB 4.6 のまま)

¹実際にはメッセージ クラスに属さないメタデータ用に、いくつかのカスタム ヘッダーを独自に追加しています。

^すべてのメッセージは少なくともキュー テーブルに入れられ、そのテーブルから削除され、監査テーブルに配置されてから、後で古い監査エントリを削除するため、多くのメッセージを取得します。 SQL Server トランザクション ログに記録されます。