Повторная попытка Ребуса 2-го уровня

Можно ли определить экспоненциальную отсрочку с рандомизацией для повтора, указанного ниже?

public class SomeHandler : IHandleMessages<DoStuff>, IHandleMessages<IFailed<DoStuff>>
{
    readonly IBus _bus;

    public SomeHandle(IBus bus)
    {
        _bus = bus;
    }

    public async Task Handle(DoStuff message)
    {
        // do stuff that can fail here...
    }

    public async Task Handle(IFailed<DoStuff> failedMessage)
    {
        await _bus.Advanced.TransportMessage.Defer(TimeSpan.FromSeconds(30));
    }
}

https://github.com/rebus-org/Rebus/wiki/Automatic-retries-and-error-handling

Например, как показано ниже: экспоненциальная задержка плюс некоторый джиттер.

Random jitterer = new Random(); 
Policy
  .Handle<HttpResponseException>() // etc
  .WaitAndRetry(5,    // exponential back-off plus some jitter
      retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))  
                    + TimeSpan.FromMilliseconds(jitterer.Next(0, 100)) 
  );

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly

https://github.com/App-vNext/Polly/wiki/Retry#overall-number-of-attempts


rebus rebus-azureservicebus
person Pingpong    schedule 16.05.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это. Способ сделать это - передать какое-то состояние в дополнительном заголовке отложенного сообщения:

var headers = new Dictionary<string, string>();

await _bus.Advanced.TransportMessage.Defer(TimeSpan.FromSeconds(30), headers);

например по подсчету попыток доставки:

var attempt = failedMessage.Headers.TryGetValue("delivery-attempt", out var x)
    ? x
    : 0;

var delay = FigureOutDelay(attempt);

var headers = new Dictionary<string, string> {
    {"delivery-attempt", (attempt+1).ToString()}
};

await _bus.Advanced.TransportMessage.Defer(delay, headers);

плюс немного больше, например, переадресовывать в очередь недоставленных сообщений, если она продолжает работать слишком долго.

person mookid8000    schedule 16.05.2019