0

我刚刚开始在 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。

4

3 回答 3

2

哦，我误读了这个问题，我以为上次重试后需要 20 分钟才能启动第二级。但我知道这是什么，而且它是可配置的！

为了支持批处理（以降低成本），消息可见时间是通过将单个 MessageInvisibleTime 乘以 BatchSize 中的数量来计算的，默认 MessageInvisibleTime 为 30000（毫秒），默认 BatchSize 为 10。再次乘以 5 次第一级重试并且您将在第一个异常发生和第二个级别开始之前的 25 分钟结束。

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

于 2013-05-15T16:03:30.580 回答
0

我的印象是，第一级重试不需要 timeoutpersister（老实说，甚至不知道它的存在），并且第一级重试仅由 Azure 队列中消息的 peek 锁定/不可见时间驱动。

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

伊夫，如果我错了，请纠正我。

于 2013-05-15T08:42:59.637 回答
0

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

我怀疑延迟来自天蓝色超时持久器，因为它负责管理重试之间的时间，但 20 分钟似乎是一个非常奇数的数字，因此无法立即解释观察到的行为。

同时，您能否尝试使用内存中的 timeoutpersister 并查看问题是否消失，这将证实我的假设。

于 2013-05-15T06:09:22.690 回答