0

Azure で NServiceBus をいじり始めたばかりですが、何らかの理由で、メッセージ ハンドラーが例外をスローしたときに、最初のレベルの再試行を完了するのに長い時間がかかります。再試行回数を 5 に設定すると、2 番目のレベルの再試行が開始されるまでに 20 分以上かかります。

遅延の原因は何ですか?

バスの構成方法は次のとおりです。

Configure.Transactions.Advanced(s =>
{
    s.DisableDistributedTransactions();
    s.DoNotWrapHandlersExecutionInATransactionScope();
});

Configure.With()
    .AutofacBuilder(container)
    .DefiningCommandsAs(t => t.IsCommand())
    .DefiningEventsAs(t => t.IsEvent())
    .XmlSerializer()
    .MessageForwardingInCaseOfFault()
    .AzureConfigurationSource()
    .UseTransport<AzureStorageQueue>()
    .AzureDiagnosticsLogger()                     
    .AzureMessageQueue()                     
    .AzureSubcriptionStorage()                     
    .UseAzureTimeoutPersister() 
    .UnicastBus()                     
    .RunHandlersUnderIncomingPrincipal(false);

参考までに: 私は、今日の開発ブランチから構築された NServiceBus を使用し、エミュレーターで実行しています。

4

3 に答える 3

2

ああ、私は質問を読み違えました。前回の再試行から 2 番目のレベルが開始されるまでに 20 分かかると思っていました。

バッチ処理をサポートするため (コストを下げるため)、メッセージの表示可能時間は、個々の MessageInvisibleTime に BatchSize の量を掛けて計算されます。デフォルトの MessageInvisibleTime は 30000 (ミリ秒) で、デフォルトの BatchSize は 10 です。これに 5 回の最初のレベルの再試行を掛けます。最初の例外が発生し、2 番目のレベルが開始されるまでに 25 分かかります。

必要に応じてこれを再構成できます。MessageInvisibleTime と BatchSize は AzureQueueConfig のプロパティであり、MaxRetries は TransportConfig (4.0) または MsmqTransportConfig (3.X) にあります。

于 2013-05-15T16:03:30.580 に答える
0

私は、第 1 レベルの再試行には timeoutpersister は必要なく (正直に言うと、その存在すら認識していませんでした)、第 1 レベルの再試行は、Azure キュー内のメッセージのピーク ロック/非表示時間によってのみ駆動されるという印象を受けました。

2 番目のレベルの再試行では、timeoutpersister が役割を果たすことを期待します (存在することがわかったので...)。

イヴ、間違っていたら訂正して。

于 2013-05-15T08:42:59.637 に答える
0

可能であれば、これについて github でイシューを開いてもらえますか? http://www.github.com/nservicebus/nservicebusで

遅延は、再試行間の時間を管理する責任がある azure タイムアウト パーシスタに起因すると思われますが、20 分は非常に奇数のように見えるため、観察された動作についてすぐに説明することはできません。

それまでの間、メモリ内の timeoutpersister を使用してみて、問題が解決するかどうかを確認していただけますか。それで私の仮説が裏付けられます。

于 2013-05-15T06:09:22.690 に答える