Question

我尝试将UseRetry与使用MassTransit和Azure Service Bus的间隔设置一起用作传输。消费者代码：

    public async Task Consume(ConsumeContext<ISimpleRequest> context)
    {
        _log.InfoFormat("Strated working on {0}", context.Message.CustomerId);
        throw new InvalidOperationException("some error");       
    }

请求服务：

var _busControl = Bus.Factory.CreateUsingAzureServiceBus(cfg =>
        {
            var host =  cfg.Host("...", h =>
            {
            });
            cfg.MaxConcurrentCalls = 10;
            cfg.ReceiveEndpoint(host, "requestconsumerbag",
                e => { e.UseRetry(Retry.Interval(2,TimeSpan.FromMinutes(5))); e.Consumer<RequestConsumer>(); });
            cfg.UseServiceBusMessageScheduler();
        });
         _busControl.Start();

发送消息后，我希望立即收到一条消息，5分钟后再播放一条消息，10分钟后再播放一封消息。但是我立刻得到一条消息，5分钟后收到两条消息，10分钟后收到3条消息，每5分钟收到3条消息。如果这是bug我怎么能编写代码来强制它像我之前说的那样工作？

Answer 1

长时间重试的问题是您超出了Azure Service Bus的锁定超时。您应该使用邮件重新传递而不是重试。

UseRetry（） - 是内联重试过滤器。它在代理的同一传递中重试相同的消息。它旨在处理瞬态失败，例如SQL超时或死锁问题。它不适用于长期重试操作。

现在配置起来有点棘手，3.4.1我不确定是否集成了重试计数（它们可能不是），但是对于每种消息类型，您都可以使用预定的重新发送。 / p>

x.Consumer<MyConsumer>(cfg =>
{
    cfg.ConfigureMessage<MyMessage>(x => x.UseScheduledRedelivery(r => r.Intervals(1000, 2000))
});

这将使用消息调度程序（在Azure中，它将使用EnqueueMessageTimeUtc调度消息）。

这在3.5中更干净，尚未发布。

UseRetry使用MassTransit设置间隔

1 个答案: