Comments 4
Думается мне, что передача промиса актору так и напрашивается на проблемы.
- Не совсем идиоматично для модели акторов, где акторы общаются посредством сообщений. Да, в приведенных примерах второй собеседник не актор, но в таком случае предполагается, что актор принимающий промис, знает, кто с ним общается. Но актору-то какое дело? Все, что он знает, — это какие типы сообщений он умеет обрабатывать. Промис трудно описать, как сообщение. Это как если бы вам прислали конверт с обратным адресом, вы положили туда письмо, но отправлять его по адресу не стали. Но откуда-то появилась невидимая рука и забрала письмо.
- Одно из преимуществ акторов в akka — разделение имплементации и деплоймента. Т.е. актор может (и, возможно, должен) быть реализован так, что способ его установки и использования извне в самом акторе никак не упоминается. Но, если мы хотим заполнять промисы, присланные извне, мы должны гарантировать локальную установку актора.
Я бы использовал такой подход, только если использование ask сильно бьет по производительности (в чем есть сомнения) и если актор гарантированно локальный. Но если актор гарантированно локальный, то в чем смысл создания актора для заполнения промисов, который внутри выполняет неблокирующую функцию, возвращающую Future? Почему бы не положить эту функцию в обычный сервисный класс с понятным интерфейсом и не вызывать его напрямую?
В общем и целом согласен. Если честно, мне даже хотелось начать заголовок статьи со слова «анти-паттерн», но не стал лепить такой ярлык.
в чем смысл создания актора для заполнения промисов, который внутри выполняет неблокирующую функцию, возвращающую Future? Почему бы не положить эту функцию в обычный сервисный класс с понятным интерфейсом и не вызывать его напрямую?Актор может быть нужен для хранения изменяющегося состояния и выполнения действий в зависимости от него. В примере с букингом из статьи это состояние — выполняется сейчас HTTP-запрос или нет. В то же время клиенты как раз и знают только про обычный сервисный класс
BookingClient с понятным интерфейсом.UFO just landed and posted this here
Из-за незнания постоянно пользовалсяКстати говоря, в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)Sign up to leave a comment.
Паттерн передачи scala.concurrent.Promise в актор: особенности использования и альтернативы