2 つのタイムアウトを使用するサガでいくつかのストレス テストを行っています。テスト中に、約 21,000 のサガが作成されます。これは 42K のタイムアウトを意味しますが、MSMQ のストレージ制限に達したためにクラッシュするまで、サガの timeoutsdispatcher キューが数十万のメッセージであふれていることに気付きました。
永続化メカニズムを RavenDB から SQL Server に切り替えてから、この動作が見られます。
誰が何が間違っているのか考えていますか?
トランスポート: MSMQ
持続性: NHibernate 使用するパッケージ:
NHibernate version 4.0.4.4000
NServiceBus version 5.2.14
NServiceBus.Host version 6.0.0
NServiceBus.Log4Net version 1.0.0
NServiceBus.NHibernate version 6.2.7
テストのセットアップ:
* エンドポイント 1 は 22000 のメッセージをエンドポイント 2 に送信しています。
* エンドポイント 2 は、そのメッセージによって開始されるサガをホストします。
* 各サガはイベントを発行し、2 つのタイムアウトを要求します。1 つは 4 分、もう 1 つは 10 分です。
観察された動作:
* エンドポイント 1 は 22K メッセージを 1 分以内に送信します。
* エンドポイント 2 (サガ) は、1 秒あたり 5 ～ 10 のメッセージを処理します。
* 4 分後に最初のタイムアウトが発生しますが、エンドポイント 2 はまだキューからのメッセージを処理しているため、新しい saga インスタンスを作成しています。
* その瞬間から、saga エンドポイントの timeoutsdispatcher キューがメッセージでいっぱいになります。
* 10 分ほど経過すると、timeoutsdispatcher キューにはすでに 170K を超えるメッセージが含まれており、まだいっぱいになっています。
* これは、MSMQ ストレージの制限に達するか、入力キューからのすべてのメッセージが処理されるためにエンドポイント 2 がクラッシュするまで続きます。後者が最初に発生した場合、timeoutsdispatcher キューのメッセージ数が減少し始め、最終的に 0 になります。