問題タブ [nservicebus3]

流暢な（Configure.With（））構文を使用して、アプリケーションのエラーキューの場所を定義できるかどうか疑問に思っていますか？

これは、MessageForwardingInCaseOfFaultConfigを介して構成されるようにnservicebus3で変更されていることに注意してください

NServiceBus 3 では、エラー キューの構成の場所が

MsmqTransportConfig を MessageForwardingInCaseOfFaultConfig に変更しましたが、MaxRetries などの MsmqTransportConfig で指定された他のプロパティがどこに行くべきかわかりません。

http://docs.particular.net/nservicebus/msmq/transportconfigを参照してください

NServiceBus 3.0 でコマンドを送信しようとしています。ICommand を実装するコマンドを送信すると、すべてが機能します。ただし、慣例を使用すると機能しません。ソースは以下。誰かが私が間違っていることを教えてもらえますか?

コマンドは次のようになります。

現在、EventStore、CommonDomain、および NServiceBus を使用するプロジェクトに取り組んでいます。 NumberOfWorkerThreads を 1 に設定すると、すべてのサービス (nservicebus - 6 つあり、それぞれに独自のイベント ストアがあります) が完全に実行されますが、 NumberOfWorkerThreads を複数に設定すると、大量のデッドロックが発生し始めます。つまり、1 分間に少なくとも 50 回発生します。すべてのデッドロックは Commits テーブルにあります。私が見つけたものから、複数のスレッドで同じ集計を更新しているように見えます。これは、カタログのインポート中に簡単に発生する可能性があり、あるスレッドで数量を更新しながら、別のスレッドで価格を更新していますスレッドであるため、両方のスレッドが同じ集計を更新しようとしています。

他の誰かがこの問題を抱えていましたか? どのように回避しましたか?

Saga で NServiceBus 3.0 ITimeoutState および IHandleTimeouts 機能を使用しようとしています。次のコードスニップがあります。次のコードは、NServiceBus.3.0.0-rc5 で問題なく正常に動作します。しかし、3.0.0 以上のバージョンで DLL を更新すると、サガのタイムアウトが期待どおりに機能せず、次の警告が表示されます。

2012-04-05 09:15:26,267 [Worker.5] INFO NServiceBus.Sagas.Impl.SagaDispatcherFactory [(null)] <(null)> - ID 9496c29e のメッセージ タイプ SomeNameSpace.MySagaTimeout のサガが見つかりませんでした- f745-4ada-8212-99e47324922b\20920. SagaNotFoundHandlersを呼び出します。

この問題を解決するのを手伝ってください。

TimeoutMessage:

サガコード：

構成:

注: 私は独自の saga 永続化機能を使用しており、 IFindSagas<MySagaState>.Using<MySagaTimeout>の実装があります。

AzureでNServiceBusをセットアップしようとしています。ローカル開発中はストレージキューを使用しており、クラウドにデプロイするときはAzureServiceBusを使用しています。何らかの理由でエラーが発生した場合、メッセージはエラーキューに移動されません。実際、エラーキューは作成されていません。

Web.configファイルには、次の構成があります。

NServiceBusを構成するとき、私は次のように呼び出します。

メッセージが失敗した場合、ログの最後のエラーは常に

これについて何か考えはありますか？メッセージングは​​機能しているようですが、機能しないのはエラー処理だけです。

ハンドラーで例外がスローされないのに、NServiceBusがメッセージをX回再結合するという奇妙な問題が発生しました。NHibernateセッションとNSBアンビアントトランザクションを扱ういくつかの情報があります。エラーがスローされないので、私は問題を100％確信しておらず、したがって、何をすべきかを実際に決定することはできません。

私はNSBをCastleWindsorで次のように構成しました。

レジスタは、次のUnitOfWorkInstallerように作業単位（NHibernateセッション）を登録します。

したがって、メッセージが到着するたびに、すべてのリポジトリで同じ作業単位が使用されます。現在のトランザクションを手動でロールバックするとエラーが発生することを読みました（理由はわかりません）。また、NSBがすべてのトランスポートメッセージに対して子コンテナーを作成し、この子コンテナーがメッセージの処理後に破棄されることも知っています。問題は、子コンテナーが廃棄されるときに、作業単位が次のように廃棄されることです。

私のハンドラーは次のように構成されています:(_unitOfWorkはコンストラクターの依存関係として渡されます）

作業単位をコミットしないと（セッションをフラッシュしてトランザクションをコミットする）、メッセージが最大再試行回数を超えて再試行されたというエラーが発生したことがわかりました。

したがって、NHibernateセッションとその作成および廃棄方法に関連しているように見えますが、作業単位内で作成されているため、セッションファクトリを実際に使用することはできません。IMessageModuleを使用してセッションを作成および破棄できることを読みましたが、そもそもエラーの原因がわからないため、これが正しい方法であるかどうかはわかりません。

要約すると：

• スコープ付きの作業単位を使用しているので、それを使用するすべてのハンドラーの依存関係が同じインスタンスを共有します（子コンテナーへのthx、ところで：子コンテナーがすべての一時的なものを処理すると考えて、作業単位を一時的なものとして設定しましたそのコンテナ内でシングルトンとしてオブジェクトを作成しましたが、作業単位が共有されていないことがわかりました。そのため、スコープとして設定されています）

• ハンドラーをusing(_unitOfWork) { }ステートメントでラップして、各処理の後に作業単位を破棄しています。

• 作業単位が破棄されると、NHibernateセッションも破棄されます

• を明示的に呼び出さないとCommit、_unitOfWorkメッセージは最大再試行回数を超えて再試行し、エラーがスローされます。

この動作の原因は何ですか？IMessageModuleがこれに対する答えですか？

NSerivceBus を使用して、特定の時間枠でのみメッセージをリモート ハンドラーに送信するシステムを構築しています。これまでのところ、すべてのメッセージを処理キューに配置し、そこからリモート ハンドラーが使用できるかどうかを確認しました。ハンドラーが使用できない場合は、境界を越えてメッセージを送信していません。これを行うために私は使用しています

しかし、NSBはすぐに挑戦し続けます。他のリスナーが数分で起動して実行されるわけではありませんが、数時間の停止期間がある可能性があるため、これは正確には効率的ではありません。

しばらくしてからバスにメッセージを再試行させる方法があるかどうか、または再試行を続けずに次の再試行までしばらく待機する方法があるかどうか疑問に思っています。私は Sagas を使用します。単純なコマンド/ハンドラー メッセージングです。

監査メッセージ ハンドラーがあり、このハンドラー内で例外がスローされた場合は、別のメッセージ ハンドラーによって処理される LogMessageInputQueue にログ メッセージを送信する必要があります。

NServiceBus ホスト プロセス内から新しいメッセージを送信することは可能ですか? AuditMessageHandler は、そのコンストラクターでハンドラー IBus を受け入れますが、呼び出し時に

例外はスローされませんが、メッセージは LogMessageInputQueue に表示されず、単に消えるようです...

すべてのハンドラとキューは同じマシン上にあります。

NServiceBus 3による子コンテナのサポートに関するページ（ http://docs.particular.net/nservicebus/containers/child-containers ）を読んだ後、Castle Windsorでは、親コンテナの一時的なコンポーネントがシングルトンのように動作することを期待していました。子コンテナ。ただし、子コンテナからのこれらの親コンポーネントの依存関係は、毎回インスタンス化されます。

Castle Windsorで親コンテナスナップショットのこの動作を実現する方法はありますか？つまり、コンテナ内のコンポーネントの一時的なものであり、子コンテナから解決された場合はシングルトンです。