問題タブ [nservicebus3]

NServicebusでホストされるプロセスを作成していて、IOCコンテナーを初期化するとともに、Self-HostedWebAPIのインスタンスを作成したいと考えています。IWantToRunAtStartupインターフェイスとIWantToRunWhenTheBusStartsインターフェイスの実装の概念的な違いを理解しようとしているので、初期化コードを適切な場所に配置できます。これらの初期化のために実装するのに適したインターフェースはどれですか？

プロセスのシャットダウン時に必要となる停止インターフェイスがあるため、WebAPIにはIWantToRunAtStartupを使用すると思います。しかし、インターフェイスは依存性が注入されていると言っているので、IOCコンテナをIWantToRunWhenTheBusStartsまたは他の場所で初期化する必要がありますか？

私はこれで少し困っています。

Andreas Öhlund はここで質問に答えましたが、彼のアドバイスを使用して動作させることができませんでした。

これが私のセットアップです：

アイデアは、特定のコマンド ハンドラーが OnProcess メソッドをオーバーライドして処理を実行すると、DomainRepository がすべてを保存するというものです。

コンポーネントを登録した方法は次のとおりです。

これらは、DomainRepository によって使用されるチェーンのすべてのオブジェクトです。ただし、コマンドを受信すると、DomainRepository は null です。DomainRepository が必要とするオブジェクトを登録する行をコメント アウトすると、実際には作成に失敗したというエラーが表示されます (Autofac DependencyResolutionException)。

他のすべてのオブジェクトはコンストラクター注入を使用することに注意してください (それらは以前の既存のプロジェクトから取得されます)。パブリック プロパティ インジェクションを使用するように変更しようとしましたが、違いはありませんでした。

ここで私が間違っていることを誰かが指摘できれば幸いです。

今日は障害物にぶつかりました。私たちの組織では、すべてのデプロイは TFS Build によって行われます。各 NSB ホスト コンポーネントがパッケージ化され、ビルド ポータルによってデプロイされる場所。NSB のスケールアウト機能を使用しようとすると、マスター プロファイルおよびワーカー プロファイルと同じコンポーネントをインストールする必要があります。パッケージ化するときに必要な引数を渡すことで、Master & Worker インストーラーを管理しました。プロセスを簡素化するために、マスターとワーカーの両方に 1 つの構成ファイルを使用し、マスターとワーカーの両方の MasterNode 構成を保持することを計画しました。大丈夫だ！本当にうまくいきました。

ポリシーに従って、構成ファイルでサーバー名を使用するべきではなく、構成ファイルで DNS エイリアスを使用する必要があります。DNS エイリアス上で MSMQ の動作を有効にすることで、これを実現しました。

ここで、実際の問題が始まります。NServiceBus.Master プロファイルは、入力キューに Node 値を追加します。DNS エイリアスをノードとして使用すると、次の例外がスローされます。

System.Exception: エンドポイントの開始時に例外が発生しました。エラーがログに記録されました。理由: 入力キュー [somequeue@some-dns.bus] は、このプロセス [SOMEDITSERVER01] と同じマシン上にある必要があります。---> System.InvalidOperationException : 入力キュー [somequeue@some-dns.bus] は、このプロセス [SOMEDITSERVER01] と同じマシン上にある必要があります。NServiceBus.Unicast.Queueing.Msmq.MsmqMessageReceiver.Init (アドレス アドレス、ブール値トランザクション) で NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.NServiceBus.Unicast.Transport.ITransport.Start (アドレス アドレス) で NServiceBus.Unicast.UnicastBus. NServiceBus.Hosting.GenericHost.Start() での NServiceBus.IStartableBus.Start(Action startupAction)

--- 内部例外スタック トレースの終了 --- NServiceBus.Hosting.GenericHost.Start() at Magnum.StateMachine.EventActionList`1.Execute(T stateMachine, Event event, Object parameter)

--- 内部例外スタック トレースの終了 --- Magnum.StateMachine.ExceptionActionDictionary 1.Execute(T stateMachine, Event event, Object parameter) at Magnum.StateMachine.State 1 eevent, Object value) at Magnum.StateMachine.StateMachine` 1.RaiseEvent (発生したイベント) で Topshelf.Internal.ServiceControllerProxy.Start() で Topshelf.Internal.ServiceCoordinator.Start() で Topshelf.Internal.Hosts.ConsoleHost.Run() で NServiceBus.Hosting.Windows.Program.Main(文字列[]引数)1.HandleException(T stateMachine, Event event, Object parameter, Exception exception)
at Magnum.StateMachine.EventActionList1.RaiseEvent(T instance, BasicEvent

質問:

NSB が現在の入力キューの有効なサーバー名として現在の MachineName を厳密に探しているときに、NSB が入力キューと他のキューに MasterNode 値を追加するのはなぜですか? NServiceBus.Master または NServiceBus.Distributor で実行するときに、なぜ NSB は MasterNode の値を無視しないのでしょうか?

それでも NSB が入力キューに MasterNode 値を追加したい場合...なぜ NSB は DNS 名を解決せず、代わりに現在の MachineName で検証を制限するのでしょうか?

最後に、次のオプションで終了します。

1.失敗したアプローチ: IHandleProfile で MasterNodeConfig の Node 値を変更します。このアプローチは気に入りましたが、欠点はほとんどありません。MasterNodeConfig は IsReadonly() のデフォルトの動作をオーバーライドせず、エラーをスローするため、機能しません。統合プロファイルを使用する場合、インストール中に Worker & Distributor キューは作成されません。

上記のコードによって作成されたランタイム エラーを回避するためのハックがあります。しかし、他のキューの作成を手動で行う場合は、これを使用できます。

2.worker と master の 2 つの異なる Config ファイルを保持し、パッケージ化します。多くの作業が実行可能に見えます。

3. マスター コンポーネントの展開中に MasterNodeConfig を削除します。

私はNSBに反対ではなく、NSBが大好きです。私はフラストレーションを表明しているだけで、理由を知りたいと思っていました。MasterNode 値を追加する理由と、解決する代わりに Environemnt で検証するだけの理由。

私はあなたからの提案を受け入れることに非常にオープンです。

NServiceBusを直接参照せずに汎用バスとして機能するレイヤーを開発するように依頼されています。これまでのところ、目立たないメッセージのサポートのおかげでそれほど難しくはありません。今を除いて、私はIHandleMessagesの独自の定義を提供し、ワイヤーアップ中にそれをマップする方法を見つけるように求められました。だから私はこのようなことを考えています：

IHandleは私たち自身の定義になります（ちなみに、これはIHandleMessagesとまったく同じです）。AppDomainを熟考し、IHandleを実装したすべてのクラスを見つけてそれらをコンテナーに登録してから、同じタイプTでMessageHandlerAdapterを登録することを期待します。

私の問題は、NServiceBusを2年近く使用しておらず、NSBパイプラインのこの種の機能をどこに接続するかを覚えていないことです。

私のブートストラッパーでは、これを行うことから始めます：

そして、InitializeNServiceBusの内容は次のようになります。

ただし、MVCアプリケーションを開くと、次のようになります。

静的プロパティにはnullインスタンスが必要であり、非静的プロパティにはnull以外のインスタンスが必要です。パラメータ名：式

エラーの原因は次のとおりです。

スタックトレース：

typesToScanをに変更すると

アプリケーションは再び機能しますが、もちろん、バスに何かを配置しようとすると、スキャンされたタイプからタイプがわからないと言って失敗します。

誰かがどこを見ればよいか知っているか、このエラーの経験がありますか？

サブスクリプションの永続性のためにRavenでNserviceBus3.3を使用する。

テスト環境でパブリッシャーからのメッセージを消費するプロトタイプアプリケーションを作成しています。アプリケーションは数週間しか使用されません。その時点で、（基本的に）現在の形式で破棄される可能性があります。

パブリッシャーがこのサブスクライバーのアウトバウンドキューにメッセージを送信し続けないようにします。事実上、私はその存在をシステムから完全に削除したいと思っています。

このサブスクライバーのすべての知識をシステムから削除するにはどうすればよいですか？

起動時に選択されたプロファイルに応じていくつかのプロパティが異なる値に設定されているサービスの具体的な実装のいくつかのプロパティを構成しようとしていますが、NSB はインターフェイスの実装でのプロパティの構成を許可していないようです。関連する場合は、コンテナーにキャッスル ウィンザーを使用しています。

最初に、次のように EndpointConfig クラスから実行されるサービス インストーラーを使用してコンテナーをセットアップします。

ServiceAdapter には、選択されているプロファイルに応じて異なる設定を必要とするインターフェイスにないいくつかの文字列プロパティがあります。

プロファイル ハンドラーは次のことを行います。

しかし、プロファイルが読み込まれると、 がスローされSystem.InvalidOperationException: Cannot configure property for a type which hadn't been configured yet. Please call 'Configure' first.ます。

インターフェイスにプロパティを追加せずに、具体的な実装でプロパティの注入を行うことは可能ですか?

バージョン3より前の推奨事項は、ディストリビューターの横で、クラスター上でスタンドアロンプ​​ロセスとしてタイムアウトマネージャーを実行することでした。（ここで詳しく説明されているように：http ：//support.nservicebus.com/customer/portal/articles/965131-deploying-nservicebus-in-a-windows-failover-cluster ）。

サテライトアセンブリとしてタイムアウトマネージャーを含めた後、ディストリビューターでスケールアウトするときにタイムアウトマネージャーを使用する正しい方法は何ですか？

サービスAの各ワーカーは、タイムアウトマネージャーを有効にして実行する必要がありますか、それともサービスAのディストリビュータープロセスのみをサービスAのタイムアウトマネージャーを実行するように構成する必要がありますか？

各ワーカーがそれを実行する場合、タイムアウトを保存するために同じRavenインスタンスを共有しますか？（もしそうなら、2人以上のワーカーが同じ期限切れのタイムアウトを同時に取得しないようにするにはどうすればよいですか？）

「人」から「ケース」への長期にわたる仕事の割り当てプロセスを表す物語があります。いくつかのイベントがそれを開始する可能性があり、プロセスの最後に割り当ての確認があり、その時点でサガが完了し、個人がケースに割り当てられます。確認を無期限に待たないように、このサガのタイムアウトを設定したいと思います。これは間違いなく有効なビジネスユースケースです。そこには問題はありません-かなりバニラです。

ツイストは、誰かがケースを保留にすると、この割り当てプロセスがブロックされる可能性があることです。サブスクライブできるイベントがあるので、割り当てのサガはケースが保留中であることを認識しますが、タイムアウトを調整するか、何らかの方法で一時停止しない限り、割り当てのサガはケースの保留が解除される前にタイムアウトになる可能性があります。これを行うのはビジネス上意味がないので、基本的に、他のイベントが発生するまでタイムアウトクロックを停止したいと思います。

これと同じ問題が数年前にここで言及されました。これはまだ不可能ですか、それともv3.xにそれを可能にする新機能がありますか？そうでない場合、それは計画された機能ですか？

ありがとう！

nuget から structuremap と structuremap.mvc4 をインストールして、ASP.NET MVC 4 Web アプリケーションを作成しました。次に、同じく nuget から nservicebus および nservicebus.structuremap パッケージを追加しました。

以前に構造マップを使用していくつかの mvc4 アプリを問題なく作成しました。また、nservicebus と構造マップを使用した基本的な pub/sub のいくつかのチュートリアルに従って、動作させました。

しかし、nservicebus を mvc4 に structuremap で入れてみたところ、うまく動作しませんでした。私が直面している問題は、以下にリストされている MVC および MVC を使用した DI の nservice バス チュートリアルでは、開発者が組み込みの依存性注入コンテナーを使用することを望んでいるように見えることです。

http://support.nservicebus.com/customer/portal/articles/894008
http://support.nservicebus.com/customer/portal/articles/894123

以前に構造マップを使用したことがある場合、nuget パッケージはリゾルバーを適切に追加し、WebActivator を使用して初期セットアップを実行します。その後、コンテナがどうなるかわからないので、Configure.With().StructureMapBuilder(StructureMap Container)でNServiceBus Builderを設定するのに使えません。

nservicebus と structuremap を asp.net MVC4 でうまく機能させるにはどうすればよいですか? オペレーターのエラーはわかっていますが、この時点で何をすべきかわかりません。また、バージョン 3 には、いくつかの気の利いた構成ロールを持つ messageendpointconfig がどこかにありませんか? それはWeb環境では当てはまりませんか？コンテナへの参照を取得して移動できると考えましたが、そうではないようです。

編集：いくつかのコードを追加

編集 2: 依存関係リゾルバーを Application_Start() に設定する場所を移動して StructureMap の問題を回避しても、NServiceBus は MessageForwardingInCaseOfFaultConfig と MsmqTransportConfig の構成を必要とします。

これらのプロパティは、エンドポイント構成のインターフェースを介して設定されたロールによって自動的に構成されることになっていることを覚えていると思いますか?