Как реализовать побочный эффект «истекает после» в Лагоме?

Я подхожу к ЛАГОМ + CQRS/Event Sourcing в первый раз, и я хотел бы реализовать поведение, как:Как реализовать побочный эффект «истекает после» в Лагоме?

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

Первые два шага просты, но как только я запускаю TimerStartedEvent и мутирую состояние, как мне «назначить» событие через определенное время? Как реализовать третий шаг?

источник

2017-02-14 Danilo Torrisi

Я лично не знаком с Лагомом, но поскольку вы указали Akka в своих тегах, я предлагаю планировщику Akka планировать сообщение о тайм-ауте вашему актеру, если это применимо к вашей ситуации. Я использовал это в приложении Orchestration для работы, которое я написал в прошлом году, что похоже на поведение: вызовите REST API, как только REST API завершит действие Completed, должен запускаться, но в то же время, как вызов REST, использует Akka Scheduler чтобы запланировать время ожидания. В зависимости от того, что приходит в первую очередь к целевому игроку, он определил, как этот вызов завершен – MattEdge

@MattEdge, это хорошая идея! Lagom построен на вершине Akka, поэтому я перечислил его в своих тегах. Единственным «недостатком» является то, что эта внешняя служба должна вызывать некоторый API для 1-й службы для передачи таймаута, поэтому в терминах CQRS она должна выполнять команду для запуска события, которое мутирует состояние. Является ли это «правильным» способом или событие должно генерироваться без специальной команды извне? –

У нас было событие, сгенерированное внутри, после того, как результаты были перенаправлены через REST API на связанный с ним Актер, который затем восстановил команду. Но если Тайм-аут произошел сначала, Actor прекратил действие, и API не смог запросить соответствующего актера (мы зарегистрировали его для целей отслеживания). – MattEdge

Я нашел возможную реализацию (фактически на самом online-auction-scala sample code).

Поскольку Lagom построен на вершине Akka, он вводит систему ActorSystem, поэтому вы можете использовать вызов system.scheduler.schedule, чтобы запланировать что-то в будущем.

Чтобы ответить на CQRS часть вопроса, образец кода делает что-то вроде:

system.scheduler.scheduler(offset, delay) { 
    checkFinishBidding() 
} 

checkFinishBidding() = { 
    registry.refFor[Entity](id).ask(SomeCommand) 
}

Так что, когда время пожаров, вы можете DEQUEUE в сущности реф из реестра и запустить команду так же, как нормальный сервисный звонок.

источник

2017-02-16 08:57:41

Это хорошее решение, но есть одна вещь, о которой нужно помнить: код примера в онлайн-аукционе еще не осведомлен о кластере. Это означает, что если вы запустите службу на нескольких узлах (рекомендуется для обеспечения устойчивости), тогда запланированная задача будет выполняться на всех из них. Чтобы этого избежать, вы можете использовать Akka [Cluster Singleton] (http://doc.akka.io/docs/akka/2.4/scala/cluster-singleton.html). –

Кроме того, я думаю, вы можете принять свой собственный ответ, если вы довольны этим :) –

Как реализовать побочный эффект «истекает после» в Лагоме?

ответ

Смежные вопросы