Akka: Как запланировать повторные попытки при сбое с растущими интервалами задержки?

Каков хороший способ заставить актера повторить что-то в случае неудачи, но с увеличивающимися временными интервалами между повторными попытками? Скажем, я хочу, чтобы актер повторил попытку через 15 секунд, затем через 30 секунд, затем каждую минуту в течение ограниченного числа раз.

Вот что я придумал:

  • метод актора, который выполняет фактическую работу, имеет необязательный параметр RetryInfo, который, если он присутствует, содержит номер повторной попытки, в которой мы находимся в данный момент.
  • в случае неудачи актор отправит себе новый ScheduleRetryMessage с retryCount + 1, а затем выдаст исключение RuntimeException.
  • другой актор наблюдает за рабочим актором, используя new OneForOneStrategy(-1, Duration.Inf(), возвращающий Resume в качестве своей директивы. У актера нет состояния, поэтому Resume должно быть в порядке
  • on receiving the ScheduleRetryMessage, the actor will
    • if retryCount < MAX_RETRIES: use Akka's scheduler to schedule sending a RetryMessage after the desired delay
    • еще: наконец сдаться, отправив сообщение другому актеру для сообщения об ошибке

Это хорошее решение или есть лучший подход?


person Robert Petermeier    schedule 28.04.2012    source источник


Ответы (2)


У вас может быть руководитель, который запускает рабочего актера. Совет из документации — объявить маршрутизатор размера один для рабочего. Супервизор будет отслеживать количество повторных попыток, а затем планировать отправку сообщения работнику по мере необходимости.

Несмотря на то, что вы создадите еще один слой актеров, мне это кажется более чистым, поскольку вы не пустите контролирующие функции в работника. В идеале вы могли бы сделать этого 1 супервайзера n рабочими, но я думаю, вам придется использовать мониторинг жизненного цикла, чтобы получить отказ от дочернего актера. В этом случае вы можете просто сохранить карту [ActorRef, Int], чтобы отслеживать количество повторных попыток для всех контролируемых исполнителей. Политика надзора будет возобновлена, но если вы достигли максимального количества повторных попыток, вы можете отправить PoisonPill вызывающему объекту ActorRef.

person jxstanford    schedule 30.04.2012
comment
Интересная идея, попробую. Спасибо! - person Robert Petermeier; 18.05.2012

В таких случаях я использую стандартный надзор. Родительский/контролирующий субъект определяет повторные попытки в пределах временного окна. Повторяющий дочерний рабочий процесс просто перепланирует сообщение, вызвавшее сбой, с задержкой в ​​preRestart().

Если повторяющийся дочерний элемент довольно сложен, вы можете подумать о подключении промежуточного актора. Этот актер просто обостряет надзор. В preRestart промежуточный актор планирует (отложенное) сообщение о перезапуске. Поскольку промежуточный актор сохранил свое состояние, он может просто перезапустить рабочий актор (с задержкой).

Как вы можете видеть, задержка может быть в preRestart или при запуске воркера.

person Latrine    schedule 13.12.2012