Конечный автомат Akka и как протоколировать Behaviors.unhandled?

У меня есть вопрос о Behaviors.unhandled, я знаю, что Akka отправляет необработанное сообщение в Dead Letter и со следующей конфигурацией также регистрирует его

akka {
 loglevel = "DEBUG"
 actor {
   debug {
    # enable DEBUG logging of unhandled messages
   unhandled = on
   }
  }
}

Ранее это обсуждалось в следующем выпуске Behaviours.unhandled и приводилось доводы в пользу типичного способа, которым Akka работает, это приемлемо и также должно регистрироваться только на уровне DEBUG.

В этот момент я, но приходит, конечный автомат является еще одним уровнем поверх Akka, и в концепциях конечного автомата эта ситуация относится к непреднамеренно управляемому переходу и, как утверждает первоначальный постер проблемы, является ошибкой, которая действительно важна в итеративном подходе. проектирование конечных автоматов.

Типичная конфигурация FSM для Akka FSM будет выглядеть следующим образом:

private val NEW: Behavior[Event] = {
  Behaviors.receive {
    case (ctx, onUserClicked(payload)) =>
      //doSomething()

    case _ => Behaviors.unhandled
  }
}

теперь, к нашему удивлению, если пользователю удается создать во время НОВОГО состояния событие onUserDoubleClicked(payload), то это ошибка проектирования на нашей стороне.

Проблема в том, что большинство из нас не будет запускать наши приложения на уровне DEBUG в продакшене, если мы столкнемся с необработанным переходом в продакшене, мы никогда не обнаружим это и не исправим в следующей итерации.

Чтобы иметь возможность отслеживать это, то, что мы должны подписаться на Dead Letters, совершенно не переходит к концепциям FSM....

По этой причине я думаю, что даже эта ситуация приемлема для обычной Akka, с концепцией конечного автомата эта ситуация должна быть зарегистрирована, по крайней мере, на уровне WARN, или должна быть предоставлена ​​​​опция конфигурации для настройки поведения, или вы видите какой-либо другой способ достижения это без огромного беспорядка кода?


scala akka akka-fsm
person posthumecaver    schedule 14.01.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не уверен, что это самый точный ответ на ваш вопрос, но я поделюсь тем, что сработало для нас в этом случае использования.

Проверьте это: https://github.com/bilal-fazlani/fsm-with-akka-typed

Мы попытались извлечь шаблон для FSM, используя akka typed. Ключом к этому шаблону является настраиваемая функция получения, т.е. Actors.scala#L31-L37" rel="nofollow noreferrer">myReceive.

Это позволяет не только самим регистрировать необработанные сообщения на любом уровне, но и отправлять отправителю ответ о том, что его сообщение было необработанным. Еще одним преимуществом этого шаблона является то, что, поскольку мы создали отдельные иерархии сообщений, такие как ReadBehaviorMessage и WriteBehaviorMessage, теперь мы вынуждены обрабатывать все сообщения "определенного состояния"; в противном случае компиляторы показывают предупреждение.

person Bilal Fazlani    schedule 14.01.2020
comment
Во-первых, спасибо за ответ, на самом деле это элегантное решение, но с небольшим беспорядком в коде, я спрашиваю себя, можем ли мы реализовать myReceive как Aspect (в данном случае AspectJ). Вокруг аспекта, капсулирующего Behavior Setup, на самом деле можно прозрачно обрабатывать Unhandled..... Я думаю, что попытаюсь реализовать таким образом.... - person posthumecaver; 17.01.2020