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

时间:2013-05-14 20:48:35

标签: azure nservicebus

我刚刚开始在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并在模拟器中运行。

3 个答案:

答案 0 :(得分:1)

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

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

如果您愿意,可以重新配置:MessageInvisibleTime和BatchSize是AzureQueueConfig上的属性,MaxRetries位于TransportConfig(4.0中)或MsmqTransportConfig(3.X中)

答案 1 :(得分:0)

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

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

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

答案 2 :(得分:0)

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

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

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