Question

我刚刚开始在Azure上使用NServiceBus，由于某种原因，当消息处理程序抛出异常时，需要很长时间才能完成第一级重试。如果重试次数设置为5，则在第二级重试之前需要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并在模拟器中运行。

Answer 1

哦，我误解了这个问题，我认为在最后一次重试后需要20分钟才能进入第二级。但是我知道这是什么，它是可配置的！

要支持批处理（降低成本），消息可见时间是通过将单个MessageInvisibleTime乘以BatchSize中的数量计算得出的，默认的MessageInvisibleTime是30000（毫秒），默认的BatchSize是10.再乘以5第一级重试，你将在第一次异常发生前25分钟结束，第二级结束。

如果您愿意，可以重新配置：MessageInvisibleTime和BatchSize是AzureQueueConfig上的属性，MaxRetries位于TransportConfig（4.0中）或MsmqTransportConfig（3.X中）

Answer 2

你可以在github上打开一个问题吗，如果可能的话，还有repro吗？在http://www.github.com/nservicebus/nservicebus

我怀疑延迟来自天蓝色超时持久性，因为那是负责管理重试之间的时间，但是20分钟似乎是一个非常奇怪的数字，所以对观察到的行为没有立即解释。

与此同时，您可以尝试使用内存超时装置，看看问题是否消失，这将证实我的超支。

Answer 3

我的印象是， 第一级 重试不需要一个timeoutpersister（甚至不知道它的存在是否诚实）以及 < em>第一级 重试仅由Azure队列中消息的查看锁定/不可见时间驱动。

对于 第二级 重试，我希望timeoutpersister能够发挥作用（现在我知道它存在......）。

Yves，如果我错了，请纠正我。

为什么要通过一级重试需要这么长时间？

3 个答案: