Паттерн передачи scala.concurrent.Promise в актор: особенности использования и альтернативы

[yahorfilipcyk]

Думается мне, что передача промиса актору так и напрашивается на проблемы.

• Не совсем идиоматично для модели акторов, где акторы общаются посредством сообщений. Да, в приведенных примерах второй собеседник не актор, но в таком случае предполагается, что актор принимающий промис, знает, кто с ним общается. Но актору-то какое дело? Все, что он знает, — это какие типы сообщений он умеет обрабатывать. Промис трудно описать, как сообщение. Это как если бы вам прислали конверт с обратным адресом, вы положили туда письмо, но отправлять его по адресу не стали. Но откуда-то появилась невидимая рука и забрала письмо.
• Одно из преимуществ акторов в akka — разделение имплементации и деплоймента. Т.е. актор может (и, возможно, должен) быть реализован так, что способ его установки и использования извне в самом акторе никак не упоминается. Но, если мы хотим заполнять промисы, присланные извне, мы должны гарантировать локальную установку актора.

Я бы использовал такой подход, только если использование ask сильно бьет по производительности (в чем есть сомнения) и если актор гарантированно локальный. Но если актор гарантированно локальный, то в чем смысл создания актора для заполнения промисов, который внутри выполняет неблокирующую функцию, возвращающую Future? Почему бы не положить эту функцию в обычный сервисный класс с понятным интерфейсом и не вызывать его напрямую?

[evis_dev]

В общем и целом согласен. Если честно, мне даже хотелось начать заголовок статьи со слова «анти-паттерн», но не стал лепить такой ярлык.

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

Актор может быть нужен для хранения изменяющегося состояния и выполнения действий в зависимости от него. В примере с букингом из статьи это состояние — выполняется сейчас HTTP-запрос или нет. В то же время клиенты как раз и знают только про обычный сервисный класс BookingClient с понятным интерфейсом.

[evis_dev]

Из-за незнания постоянно пользовался onComplete или onSuccess методами из akka-http.

Кстати говоря, в GenericMarshallers есть полезные маршаллеры и для других стандартных типов (например, Option), которые часто удобно повторно использовать.

Не знаю упоминалось ли в статье, но еще одна важная, на мой взгляд тема связанная с actor-ами и future: doc.akka.io/docs/akka/current/general/jmm.html#actors-and-shared-mutable-state

В статье явно эта тема не затрагивалась, но именно по этой причине в акторе HttpBookingClient.ClientActor обратное изменение функции поведения на default инициируется отправкой сообщения себе:

p.future.onComplete(_ => self ! Completed)