Комментарии 70
Пока, у меня возник, только, один вопрос: а почему агенты обязаны быть объектами — экземплярами классов C++? Что мешает основную инфраструктуру разрабатывать с применением классов, но сами агенты реализовывать как структуры, которые управляются ядром определённым образом?
И, конечно, это немного SmallTalk-подобная архитектура заставляет задуматься об упорядочивании агентов по типам (по типам сообщений, по задачам, по особенностям данных), и это упорядочивание (типа декомпозиции системы) само по себе способно разрешить проблему перегрузки агентов.
С другой стороны, мне очень нравится идея с удалением агентов. Я представил себе, как бы упросилась жизнь разработчика, если бы каждый объект должен был бы постоянно уничтожаться и воссоздаваться заново. Это обеспечило бы стабильность работы (объект почти всегда в корректном состоянии), надёжность доставки сообщений (необработанные сообщения можно всегда доставить новой версии объекта; а, если, осуществлять скрещивание или расщепление объектов с элементами генной инженерии?), при этом, сами сообщения тоже могут быть объектами-агентами особого сорта (могут приниматься другими объектами, но сами могут обрабатывать сообщения).
Пока, у меня возник, только, один вопрос: а почему агенты обязаны быть объектами — экземплярами классов C++?
Ну тут, скорее, смешение деталей реализации и опыта использования. В агенте должны быть какие-то атрибуты, которые нужны самому фреймворку для обслуживания агента. Удобно это оформлять в виде агента. Кроме того, практика показала, что в реальной жизни агенты очень быстро перерастают маленькие однострочники и могут достигать размеров в сотни, а то и в тысячи строк. Плюс временами активно используется наследование. Т.е. какой-то базовый класс агента вбирает в себя основной функционал, а другие классы-наследники только уточняют его работу. Так что использование здесь объектов и принципов ООП себя, на мой взгляд, оправдывает.
Кроме того, у нас есть такое понятие, как ad-hoc агент, когда агент просто конструируется из лямбда-функций без необходимости определять класс агента и создавать его экземпляр. Вот простой пример. А вот еще один — тут агент ponger реализуется в виде ad-hoc агента с лямбдой-однострочником.
С SourceForge можно сразу бинарники для MSVC++ загрузить.
Использовал Akka+Scala. Был в начале воодушевлен идей акторов. Попробовал Akka, был несколько разочарован. В итоге для классического подхода считаю нужно выбирать Future, далее объясню что имею ввиду.
Почему? Мы работаем c актором просто как с ActorRef без типа, соответственно нет гарантий на стадии компиляции что сообщение передается конкретному актору(типу акторов) и актор может его обработать в принципе, нужно писать тесты. Нет гарантий на стадии компиляции что актор инициализируется корректно, из-за отсутствия типа, например передаются не корректные параметры как аргументы конструктора.
По итогу мы получаем такую цепочку боли:
1) Нет гарантии что все акторы инициализировались правильно при старте приложения.
2) Нет гарантий что все акторы передают сообщения тем акторам которым должны и принимаю сообщения от тех от которых должны.
3) Нет гарантии что актор сможет обработать пришедшее сообщение. Вы добавляете передачу сообщения в один актор но можете пропустить добавление его обработчика в один из акторов который потенциально его может принимать, и это из-за отсутствия типизации.
Т.е. нужно писать очень много тестов.
В целом хорошо описано тут: http://stew.vireo.org/posts/I-hate-akka/
Сейчас вижу только одно применение акторам, но сильное (по сути это и есть их суть, замысел) — построение stateful вместо stateless приложений когда на каждую сущность в системе ровно один актор и даже если это распределенная система(через akka claster). Если строить систему таким образом то получается очень много преимуществ — отсутствие необходимости кэша между backend'ом и хранилищем данных и состояния гонок, потому что за каждую сущность отвечает ровно один актор хранящий свое состояние и он обрабатывает все приходящие к нему данные последовательно. В случае распределенной системы akka cluster — это секционирование(partitioning) из коробки. Но остается все же вопрос как выполнить транзакцию которая захватывает больше одного актора(т.е. сущности).
В итоге для классического подхода считаю нужно выбирать Future, далее объясню что имею ввиду.
Для классического подхода к чему?
Нет гарантии что все акторы инициализировались правильно при старте приложения.
С Akka не работал, поэтому не сильно понимаю, как такое возможно.
Нет гарантий что все акторы передают сообщения тем акторам которым должны и принимаю сообщения от тех от которых должны.
Ну вот это как сильная, так и слабая сторона. Сильная сторона в том, что позволяет писать в стиле fire-and-forget, а так же позволяет легко подменять отправителей/получателей. С другой стороны, все проверки только в run-time. Но, опять же, за счет легкой подмены отправителей/получателей тестировать легко, а ведь тестировать саму обработку сообщения все равно нужно, даже если правильность подписки по типам гарантируется в compile-time.
Кроме того, это не столько проблема самой Actor Model, скорее отдельных ее реализаций. В CAF, например, делают каких-то типизированных акторов, у которых соответствие типов сигнала/слота проверяется в compile-time. Я, правда, не сильно понимаю, насколько это полезно на практике, мы как-то с подобными проблемами не сильно сталкивались. Да и с расширяемостью не очень понятно.
Плюс очень сильно жизнь упрощается, когда у фреймворка есть средства трассировки процесса доставки сообщений.
построение stateful вместо stateless приложений когда на каждую сущность в системе ровно один актор
Об этом речь пойдет во второй части статьи.
Суть акторов, что любой актор может послать любое сообщение любому актору и только актор сам решает, может он обработать это сообщение или нет. Это позволяет строить очень гибкие решения.
Иначе у вас получится обычный ООП с дерганьем методов и сильной связанностью. Поэтому вам и Future больше подходит для задач чем акторы.
Собственно никто и никогда не обещал, что акторы везде хорошо подходят.
Писал несколько проектов на Akka, вообще ни разу не сталкивался с неправильной инициализацией акторв и всеми теми проблемами что вы описали. Даже новички так не ошибались в коде.
Все эти проблемы выглядят теоретиконадуманными или притянутыми за уши. И на практике возможны только у совсем пофигистов новичков, которые копипастят код со SO не понимаю что и как они делают…
Потому что ровно все те же проблемы есть у всех языков и всех фреймворков:
1. Более менее еще в тему, хотя проблема правильно иницализации пристутствует во многих фреймворках.
2. Таких гарантий нет ни в одном приложении. Это все зависит только от разработчика. Он может забыть что угодно. В одном месте добавил метод, в другом забыл его «дернуть».
3. Таких гарантий тоже нет ни в одном приложении, см п 2.
И да, на такие вещи помогут только тесты, нет других вариантов пока.
А как вы планируете типами гарантировать, что актор послал сообщения тем кому «должен» послать и от кого «должен» принять?
Объективно, бывают случаи, когда хорошо было бы заранее знать, что отсылать сообщение типа x агенту А бесполезно, он такие сообщения в принципе не обрабатывает. Обычно такое бывает в результате разделения большого старого актора на несколько новых, поменьше. Раньше актор А обрабатывал x, теперь это делает актор B.
Но, опять же, это палка о двух концах. Т.к. со временем актор A вновь может начать обрабатывать x, только уже совсем по-другому.
Так что тут, имхо, нет однозначных преимуществ у проверок в compile-time и в run-time, у обоих подходов сильные стороны превращаются в недостатки и наоборот.
А как вы планируете типами гарантировать, что актор послал сообщения тем кому «должен» послать и от кого «должен» принять? Может все таки не «должен», а «может»? )
…
- Таких гарантий нет ни в одном приложении. Это все зависит только от разработчика. Он может забыть что угодно. В одном месте добавил метод, в другом забыл его «дернуть».
- Таких гарантий тоже нет ни в одном приложении, см п 2.
Про интерфейсы в ООП не слышали? А про статическую типизацию? То и другое вместе дает целый ряд определенных гарантий. Модель акторов просто лишает разработчика всего вот этого. В Akka, например, для решения этой проблемы существуют Typed Actors (которые сейчас в процессе замещения проектом Typed Akka). По сути, из актора получается все тот же объект из ООП, со строго типизированным интерфейсом, дающим определенные гарантии, но с асинхронным вызовом методов (с пересылкой сообщений, асинхронными ответами, тайм-аутами и прочими акторскими плюшками "под капотом"). И это гарантирует на этапе компиляции, что сообщение будет отправлено нужному агенту, а не кому попало. Иначе приложение просто не скомпилируется. А если агент на каком-то этапе разработки приложения перестанет обрабатывать сообщения какого-то типа — то из его интерфейса пропадет соответствующий метод, и компилятор об это сообщит, и покажет все места, в которых кто-то все еще пытается этот метод дергать.
И это гарантирует на этапе компиляции, что сообщение будет отправлено нужному агенту, а не кому попало.
Все не так однозначно.
Во-первых, кому попало все равно можно отправить. Если вы отсылаете сообщения акторам A и B, и по ошибке отсылаете сообщение актору A вместо актора B, то вы все равно ошибаетесь с адресатом.
Во-вторых, как сказано в статье, даже если вы отсылаете сообщение правильного типа правильному агенту, вам все равно никто в compile-time не гарантирует ни доставку сообщения, ни его корректной обработки.
Так что в теории выгода от проверок в compile-time есть и она выглядит существенной. На практике все равно без тестирования прогона всех нужных сообщений не обойтись. Что уменьшает стоимость этого аргумента.
Во-первых, кому попало все равно можно отправить.
Ну, с типизацией совсем уж кому попало отправить уже не получится, как минимум принимающий интерфейс должен будет соответствовать отправляемому сообщению. Что уже отсекает довольно много возможных неприятностей. А если спрятать актора за фасадом какого-ниубдь интерфейса в духе Active Object, то добавятся еще названия методов, и возможность сделать что-то не так сводится к минимуму.
В общем, типизированные акторы не на ровном месте появились, и развитие в этом направлении продолжается.
А то на моем опыте это совершенно не проблема. Гораздо больше неприятностей доставляют такие ошибки, когда подписку на сообщение вообще забывают сделать или же забывают ее сделать в нужном состоянии.
Но вот случаи, когда агенту отсылается какое-то не то сообщение — это какая-то экзотика.
вы на своем опыте поимели много неприятностей из-за нетипизированности акторов?
Да, иначе бы я об этом не писал. Статья же о шишках — вот я своих еще в копилку подбросил. Могу вспомнить пару-тройку неудобств из-за отсутсвия типизированного интерфейса у акторов:
- Отсутствие подсказок в IDE. Что приводит к частой необходимости лезть либо в исходный код актора, либо в документацию (если это сторонняя библиотека, и/или поведение в исходном коде не очевидно). Это ощутимо замедляет процесс разработки.
- Дополнительные тесты на то, что актор не отправляет ничего "левого" другому актору. С типизированными интерфейсами это невозможно "by design". Опять разработка замедляется: часть работы компилятора перекладывается на программиста.
- С эволюцией приложения какой-то компонент обновляется, какие-то эти обновления подхватывают, а какие-то обновить забыли — и они продолжают использовать старый "интерфейс". Компилятор это не отлавливает, приходится сталкиваться с последствиями в рантайме и долго и нудно разгребать логи, чтобы понять, где причина. А ошибки рантайма, как известно, гораздо более дорого обходятся в конечном счете. С типизированными интерфейсами вероятность такой ситуации — минимальная. Разве что если в методе два однотипных аргумента зачем-то местами поменять.
Больше так не вспомню, это пару лет назад было, и с тех пор я весь проект перевел таки на фьючерсы, а от акторов совсем отказался (несмотря на ряд их неоспоримых достоинств). А вообще, в интернетах много холиваров на тему "статическая типизация vs динамическая", почитайте как-то на досуге — там можно встретить много интересного и полезного. По обе стороны баррикад.
Правильно ли я понимаю, что этот опыт был получен на основе использования Akka в Scala/Java?
Да, Akka+Scala.
У нас зачастую типы сообщений были вложенными типами для агентов. Т.е., у нас было что-то вроде (пример грубый, просто для иллюстрации):
class file_agent {
public :
// Сообщения, которыми оперирует агент.
struct write_data {...};
struct loaded_data {...};
...
};
Основное взаимодействие у нас происходило между агентами, которые входили в одну группу (у нас это называется кооперацией). Создание таких агентов выполняется в одном месте, все взаимосвязи устанавливаются там же, поэтому шансов допустить ошибку меньше.
Тем не менее, если у пользователей акторных фремворков есть желание работать с типизированными интерфейсами и иметь контроль типов в compile time, то об этом нужно задуматься. Вот, например, что-то подобное вас бы устроило? Или этого недостаточно и хочется чего-то еще более строгого?
Дело в том, что это не совсем даже и проблема, это скорее просто неудобство. И только для тех, кто привык к строгой типизации и проектированию через интерфейсы. Может быть, это вообще попытка натянуть ужа на ежа, и акторы по природе своей должны быть нетипизированными. В Akka до сих пор ищут элегантное решение этого вопроса: текущая реализация, экспериментальная новая версия. Ведь помимо типизированных ящиков для сообщений там всплавает еще ряд тонкостей и нюансов: смена поведения, типизированный отправитель обрабатываемого сообщения, и т.п. И сам язык должен быть достаточно гибким, чтобы все эти нюансы учесть.
смена поведения, типизированный отправитель обрабатываемого сообщения
А в чем суть этих нюансов? Хотя бы в двух словах? Ну или ссылку на какое-то описание. Реально поможет лучше разобраться.
Ну так я же привел выше 2 ссылки, там даже с примерами кода на Scala. Там же и для Java, думаю, можно найти аналогичные разделы в доках, если есть необходимость. А в двух словах: если поведение актора меняется (в ответ на сообщение) — то в типизированном интерфейсе это должно как-то отражаться. А типизированный sender: актору должен быть известен тип отправителя, когда он получает от кого-то сообщение. Для ответа, например.
На счет поведения: походу, во втором документе они сами пришли к выводу, что это статически непроверяемо. Да и вообще вряд ли нужно. Особенно, если на актора смотреть как на конечный автомат: внешний наблюдатель знает только общий список входящих сообщений для КА, но не должен иметь представления о том, какие сообщения актуальны для КА в его текущем состоянии. Тем более, если брать в рассмотрение иерархические КА, в которых реакция на входящее сообщение может наследоваться из родительского состояния.
По поводу ответов тут вроде как все тривиально: типизированные почтовые ящики/каналы в качестве получателя ответа успешно закрывают эту тему.
Насчет поведения: все еще усложняется тем, что одному актору-конечному автомату могут слать сообщения несколько других, и у них между собой будет рассинхронизация, так как нет никаких гарантий, что между двумя сообщениями от одного актора не прилетело что-то от другого и не изменило состояние конечного автомата. На этапе компиляции я не вижу возможности эту проблему как-то решить.
По поводу ответов — мне это таким уж тривиальным не кажется. Есть актор A, он получил сообщение M. От кого он его получил? Какой тип имеет отправитель этого сообщения? Какие сообщения он может принимать в ответ? Гарантировать тип отправителя можно, например, в том случае, если "зашить" его в протокол, то есть ограничить интерфейс с двух сторон: что вот это сообщение может приходить только от такого типа акторов, и только такому типу акторов. В Akka этот механизм тоже претерпевает эволюционные изменения, и об этом по приведенным ссылкам тоже упоминается.
На этапе компиляции я не вижу возможности эту проблему как-то решить.
А зачем ее решать на этапе компиляции?
Тут скорее вопрос владения ссылкой на актора-получателя. Если ссылкой владеет только один отправитель, то никаких сложностей нет, идет обычное взаимодействие 1:1. Если ссылкой владеет N отправителей, то ничто не препятствует взаимодействию N:1. Если конкретного программиста N:1 для конкретного актора-получателя не устраивает то… То такому программисту нужно выдумывать для своей задачи какой-то аналог Rust-овских «заимствований» для actor_reference. Чтобы добиться гарантий того, что в конкретный момент времени actor_reference доступен только одному отправителю.
Только есть большие сомнения в том, что многим потребуется что-то подобное.
Гарантировать тип отправителя можно, например, в том случае, если «зашить» его в протокол, то есть ограничить интерфейс с двух сторон: что вот это сообщение может приходить только от такого типа акторов, и только такому типу акторов.
А зачем это нужно? В каких практических задачах это может потребоваться?
Я еще могу понять, когда на уровне контракта пытаются описать, что в ответ на сообщение X может быть получено Y или Z. Но чтобы при этом требовалось, что ответ на X должен получить только актор типа N, это уже что-то противоречащее здравому смыслу. Ибо такая типизация мешает переиспользованию акторов.
Какой-нибудь актор connection_pool сегодня используется в одном проекте, где он общается с акторами temperature_sensors, а завтра будет использоваться в другом проекте, где он общается с акторами risk_managers. Введение требований к типам агентов-consumer-ов приведет к тому, что эти требования придется удовлетворять и для temperature_sensors, и для risk_managers. Ну и зачем это нужно, если temperature_sensors и risk_managers и так будут вынуждены приспосабливаться к интерфейсу connection_pool-а на уровне сообщений acquire, release, take и failure?
А зачем ее решать на этапе компиляции?
А зачем это нужно? В каких практических задачах это может потребоваться?
Все это нужно для обеспечения типобезопасности. Все эти вопросы Akka пытается решить. Раз пытается — значит, видит необходимость.
Введение требований к типам агентов-consumer-ов приведет к тому...
Это ведь не совсем ограничение на тип, это ограничение на реализуемый ими интерфейс. В Akka приводится пример реализации протокола, когда в ответ на вот такое сообщение актор может отправить вот такое сообщение, а следом за этим сообщением "тип" (интерфейс) актора меняется на вот такой (то есть он уже может получать-отправлять другие сообщения). Протокол ограничен типами с двух сторон, то есть, актор A1, получая сообщение типа M1, уверен на этапе компиляции, что его ему отправил актор A2, которому можно ответить сообщением M2. Как-то так.
Добавлено: отправка сообщения типизированному актору — это же ведь только половина задачи типизации. Актор же должен иметь возможноть точно так же типобезопасным способом на это сообщение ответить.
В данном случае, A1 и A2 — это всего лишь интерфейсы, которые говорят о том, что эти акторы могут принимать сообщения M1 и M2 соответсвтенно. То есть, если завтра вашему connection_pool-у захочет отправлять сообщения другой актор — он просто реализует необходимый интерфейс для получения типизированных ответов от connection_pool-а. При этом, в самом connection_pool ничего не нужно менять, так как сообщения-ответы не меняются и интерфейс любого получателя ему известен заранее.
В данном случае, A1 и A2 — это всего лишь интерфейсы, которые говорят о том, что эти акторы могут принимать сообщения M1 и M2 соответсвтенно.
Ну так в Модели Акторов M1 и M2 и есть те самые интерфейсы A1 и A2. Просто в статически типизированных ОО языках мы привыкли, что интерфейсы выражаются через перечисление методов. А в Модели Акторов интерфейсы выражаются через перечисление сообщений.
Все это нужно для обеспечения типобезопасности.
Типобезопасность не является самоцелью, как я надеюсь. Akka, как и SObjectizer, — это инструмент для решения практических задач. Если типобезопасность в каких-то задачах становится настолько важной, что этому уделяется внимание, то должны быть какие-то примеры.
Пока же разговор идет о том, что раз мы находимся в рамках статической типизации, то хотим иметь ее везде. В том числе и при взаимодействии акторов посредством асинхронных сообщений. Только вот проблема в том, что преимущества статической типизации для синхронных вызовов — они понятны и очевидны. А вот типизация асинхронного обмена сообщениями… Не понятно, и не очевидно.
Протокол ограничен типами с двух сторон, то есть, актор A1, получая сообщение типа M1, уверен на этапе компиляции, что его ему отправил актор A2, которому можно ответить сообщением M2.
Но зачем это? Это все может решаться и без попыток подружить Модель Акторов со статической типизацией.
Типобезопасность не является самоцелью, как я надеюсь.
Да. Как и молоток. Это лишь удобный инструмент, который помогает решить некоторые задачи. Я привык к этому инструменту, он очень плотно вписан в мой рабочий процесс. И его потеря для меня очень ощутима.
Но зачем это? Это все может решаться и без попыток подружить Модель Акторов со статической типизацией.
Мы топчемся по кругу, вы не находите? Можете прочитать всю ветку комментариев еще раз, все мои доводы там перечислены. На всякий случай обобщу: просто потому что некоторые люди предпочитают типобезопасность другим решениям. Просто потому, что некоторые люди считают, что типобезопасноть решает многие проблемы эффективнее других подходов. Просто потому, что каждый выбирает для себя инструмент, которым лично ему удобнее работать.
Потому собственно и топчемся, что нет внятного ответа на вопрос, зачем нужна такая навороченная типизация обмена сообщениями. Есть только очень абстрактное «потому что с типами лучше чем без них». Но речь ведь идет не о сферическом коне «статика vs динамика», а конкретно об интерфейсе для сообщений в акторах. И вот тут нет внятного объяснения что вылечит весь этот геморрой с такой жесткой типизацией интерфейсов.
Потому что на практике все описываемые проблемы вообще никак не ощущаются. Все примеры проблем, здесь в каментах, очень абстрактные и ничего толком не объясняют.
Все что я пока вижу, это попытку сделать из акторов обычный ООП с интерфейсами. И я не понимаю зачем это? ООП уже есть, зачем из акторов делать ООП мне не понятно…
Я привел несколько вполне конкретных доводов из моей личной практики в пользу статической типизации акторов. Их дополнил eao197 еще парой примеров. Если вам все еще мало конкретики — то в тех же сферических холиварах "статика vs динамика" их есть еще, и к акторам это тоже вполне применимо.
Более того, есть мнение, что изначальная задумка ООП-подхода основывалась как раз на агентах, которые посылают сообщения друг другу. Но потом что-то пошло не так, и сейчас мы имеем ООП с синхронным дерганьем методов вместо пересылки сообщений. Хотя, попытки реализации объектов на сообщениях были (Objective-C, например).
Можете прочитать всю ветку комментариев еще раз, все мои доводы там перечислены.
Уверяю вас, все доводы прочитаны и осмыслены. Более того, я сам сторонник статической типизации и для проектов свыше 5KLOC вряд ли выберу динамически-типизированный язык.
Я продолжаю выпытывать у вас подробность из-за того, что отвечаю за разработку акторного фреймворка и пытаюсь понять, можно или из того, что вы рассказываете получить аргументы «за» для добавления в фреймворк дополнительной функциональности.
Поэтому и интересны примеры из жизни, дабы идею поддержки более строгой статической типизации было проще «продать» остальной команде.
Если я единственный человек, который в принципе заговорил о типизации акторов (безотносительно вашего фреймворка, замечу, так как мой опыт основывается исключительно на Akka+Scala) — то ваше желание сразу же внедрить подобную функциональность в ваш фреймворк лично мне кажется несколько поспешным. Если ваши пользователи им и без того довольны — то оно им может быть и не нужно.
Если же были запросы от ваших пользователей — то вам лучше поспрашивать у них, зачем им это может быть нужно. Потому что Akka — это другой фреймворк, а Scala — другой язык и другой подход к программированию. Может быть, то, что применимо и удобно на Scala и Akka — совсем ненужно, неудобно или неприменимо к вашему фреймворку и C++.
Тем не менее, про примеры. Примеры с рефакторингом хороши, даже не смотря на то, что мы сами по каким-то причинам с подобными проблемами не сталкивались, представить себе их актуальность несложно.
А вот за примерам того, что агент-обработчик заинтересован в знании типа агента-отправителя, приходится идти куда-то далеко… :(
Ну и зачем это нужно, если temperature_sensors и risk_managers и так будут вынуждены приспосабливаться к интерфейсу connection_pool-а на уровне сообщений acquire, release, take и failure?
Ровно затем же, зачем нужна типобезопасность и интерфейсы в классическом ООП: там ведь тоже объекты вынуждены приспосабливаться к интерфейсам других объектов, посредством вызова методов друг друга. Так зачем интерфейсы, если и без них объект A может вызвать метод acquire у объекта B? Сообщения — это по сути те же методы. Только в интерфейсе они нигде не прописаны. В общем, эти все вопросы из разряда PHP vs Java. В PHP можно сделать $anyVar->anyMethod(), и получить ошибку на этапе исполнения, а Java этого не пропустит еще на этапе компиляции.
P.S. Прошу прощения за раздробленный ответ.
там ведь тоже объекты вынуждены приспосабливаться к интерфейсам других объектов, посредством вызова методов друг друга
Не совсем так. Если есть что-то вроде:
class connection_pool {
public:
optional<connection> acquire();
...
};
А вот когда заходит речь о том, что для отсылки ответного сообщения take нужно, чтобы отправитель имел какой-то специальный тип take_acceptor, то здесь уже возникают проблемы с придумыванием конкретных примеров из практики, которые могли бы это все оправдать.
В общем, эти все вопросы из разряда PHP vs Java. В PHP можно сделать $anyVar->anyMethod(), и получить ошибку на этапе исполнения
Не совсем так. Принципиальная разница в том, что если в динамически-типизированном языке вы вызываете у объекта метод, которого у объекта нет, то вы гарантированно получите ошибку в run-time. В случае же с акторами, если вы отправляете актору сообщение, которое актор не поддерживает, вы об этом не узнаете. Более того, если вы отсылаете актору сообщение, которое он поддерживает, но сообщение до получателя не доходит, то вы имеете точно такой же эффект. Т.е. вы якобы получаете гарантии в компайл-тайм, которые ничего не стоят в ран-тайм.
И еще один момент. Если нетипизированные actor_reference настолько мешают жить, то ведь очень легко они превращаются в типизированных. Достаточно сделать что-то вроде:
namespace connection_pool {
struct acquire { ... };
struct release { ... };
...
class actor_ref : protected actor_reference { ... };
...
};
connection_pool::actor_ref pool = make_actor<connection_pool::pool_actor>(...);
нам не нужно заботиться о том, какой интерфейс имеет объект, который дергает connection_pool::acquire
Верно, потому что при этом мы имеем тип возвращаемого значения, которое получим, вызвав метод aquire(). А чтобы узнать, можно ли вообще отправить актору сообщение aquire, что он на него ответит, и должен ли вообще отвечать — нужно лезть либо в документацию к нему, либо в исходный код, что не всегда практически осуществимо. И это сильно понижает производительность труда программиста. Мою, по крайней мере.
Как вы, с помощью статической типизации, интерфейсов и прочего сможете гарантировать, что актор послал сообщение тем, кому должен?
Вот по пунктам распишие.
Если конкретизировать, то выражение «Гарнтия того что актор послал сообщение тому кому должен», означает, что вы в компайл тайме проверили, что какое-то сообщение актор отправил и какое-то сообщение актор получил. Для этого компилятору необходимо знание о том, что вообще должно происходить.
Другими словами, компилятор должен знать, что если мы создали метод, то кто-то где-то должен его обязательно его «дернуть». Как вы себе представляете это решение использую статическую типизацию?
Статическая типизация поможет только провериь, что мы передаем конкретный тип сообщения, и этот тип может обработаться актором. Но никак не может гарантировать что мы вообще посылаем такое сообщение и уж тем более не может гарантировать доставку сообщений.
У вас все смешалось в кучу.
Если говорить про акторы в целом, то т.к. под акторам подразумевается распределенная система, говорят что нет гарантий доставки. Но не потому что это акторы, а потому что система распределенная. Это обычная для новичков подмена понятий. На классическом ООП с Future то же нет гарантий доставки.
В общем случае вообще нет гарантии доставки сообщений в распределенной среде. Это в принципе не решаемая сейчас проблема. Ее только можно минимизировать разными способами. Гуглите «Задача двух генералов».
В рамках же одного приложения, гарантия доставки сообщения ровно такая же как и при вызове обычного метода.
Т.е. единственная проблема акторов в Акка, это не забыть сделать обработку сообщения в акторе.
Но эту ошибку точно так же легко допустить в любом коде и без акторов, забыв дернуть нужный метод.
P.S. Интерфейс с типами, в который обернут актор не гарантирует, что сообщение именно будет отправлено. А только то, что оно может быть отправлено именно с таким типом.
Программист легко может забыть его отправить при рефакторинге)
Это вы вообще все в кучу смешали. Если уж вашими категориями рассуждать — то где вообще гарантия, что программист Василий написал программу, а не ушел пить кофе и играться в приставку?
Гарантия доставки сообщений — это отдельная история. Причем тут она к статической типизации?
Я говорю о том, что есть конкретные гарантии, которые предоставляет статическая типизация и статически типизированные интерфейсы. Я говорю о том, что я, выбрав для себя статически типизированный язык, привык к этим гарантиям, привык работать именно в этой парадигме, и вижу в ней лично для себя целую кучу удобств и бонусов. Я говорю о том, что нетипизированные акторы в статически типизированном языке лишают меня тех гарантий, которые дает мне этот язык. И заставляют меня работать так, как будто я перешел на какой-нибудь скриптовый язык с динамической типизацией. И мне это не нравится.
Это как если бы вам по почте прислали гаечный ключ, а на посылке написали, что это отвертка. А вы бы по внешнему виду не смогли бы понять, что это, попробовали этим открутить шуруп — но у вас не получилось, и только тогда вы поняли, что это не отвертка. Или может отвертка, а вы просто не так крутите? Или это не шуруп у вас вовсе? Вот в статически типизированном языке если вы имеете шуруп — то вы имеете шуруп, и его интерфейс это гарантирует. И если вы ждете отвертку — то вы получите отвертку, потому что ключ на ее место физически в посылку не влезет, и вам не смогут его отправить. А вот соизволил ли отправитель явиться на почту, не вскрыли ли посылку по пути, не сошел ли с рельс грузовой поезд — это уже к вопросам типизации не относится, это все из совершенно другой плоскости, не нужно мух с котлетами мешать.
Я говорю о том, что нетипизированные акторы в статически типизированном языке лишают меня тех гарантий, которые дает мне этот язык.
Статическая типизация никуда не девается. Вы вешаете обработчик на сообщение типа Msg1 и в этот обработчик приходит только сообщение типа Msg1. Сообщения других типов в ваш обработчик не попадут.
А вот как раз гарантии доставки и отсылка сообщения по другому адресу отношения к типизации не имеет. И из-за этих гарантий работа с Моделью Акторов имеет свои специфические особенности.
Статическая типизация никуда не девается.
Внутри самого актора — да. Но сам по себе актор — вещь абсолютно бесполезная. Для того, чтобы он работал и приносил пользу — он должен взаимодействовать с внешним миром. Вот для формализации этого взаимодействия в ООП и существуют интерфейсы. А нетипизрованные акторы их начисто лишены. Кто-то может от этого испытывает какое-то особое наслаждение, кто-то выбирает своим рабочим инструменом языки с динамической типизацией, — это их неотъемлемое право. Но лично для меня, отсутствие типизированных интерфейсов — это большое неудобство.
Но лично для меня, отсутствие типизированных интерфейсов — это большое неудобство.
Тут выше уже говорили про такой аспект, как распределенность. Жизнь показала, что жестко специфицированные интерфейсы в распределенных системах (те же самые CORBA и DCOM) отнюдь не так хороши, как жесткотипизированное взаимодействие в рамках одного процесса. Например, сложности с расширением интерфейсов со временем. Тогда как взаимодействие систем на основе обмена сообщениями (причем с поддержкой разных версий) оказывается удобнее и гибче.
Не вижу, как типизация может помешать системе обмениваться сообщениями. Типизированный актор просто добавляет удобный "фасад" для программиста в виде интерфейса взаимодействия, который уже является подсказкой, что из себя представляет этот актор, в отличие от безмолвного и безликого ActorRef. И ограничивает возможные способы неправильного применения. Упрощает поддержку в будущем, читабельность кода, время вхождения в проект для новичков. В общем, одни бонусы. А под капотом всего этого — все тот же актор, все та же пересылка сообщений, все та же асинхронщина.
Язык, фреймворк и психическая адекватность программиста. А так-то да, кошмар сплошной кругом. Бывает, булочку в магазин выйдешь купить — а где гарантия, что то вообще булочка, а не рогалик, а за прилавком не марсианин переодетый, а человек?
Язык, фреймворк и психическая адекватность программиста.
Когда речь заходит о гарантиях во время компиляции, все, что касается самого программиста, учитывать не стоит. Единственная гарантия, которую может дать фреймворк — это выброс исключения при попытке приведения нетипизированной ссылки на удаленного актора (грубо говоря actor_reference<>) к типизированной (грубо говоря, к actor_reference<Mgs1, Msg2, Msg3>). Вас устраивает, если на этом этапа в run-time вы получаете исключение (ведь нет никаких гарантий в compile-time, что каст всегда пройдет успешно)?
Само собой, у компилятора есть свои границы. Дальше — вопросы грамотного проектирования и конфигурирования системы. Но то, что он не может гарантировать вам вообще всего на свете, написать за вас программу и сварить вам кофе — не повод обесценить все то, что он может сделать, и от этого всего отказаться. Это как заявить: ай, бывают случаи, когда подушки безопасности не помогают, так зачем их вообще в автомобили ставить, давайте не будем.
Хорошо когда компилятор может проверить, что в акторе сть обработчик нужного типа сообщения и соответсвенно дать гарантию, что именно этот тип может обработаться актором. Соответсвенно при рефакторинге он может указать на ошибку этого типа.
Другой вопрос, что на практике я даже теоретически не вижу, где это мне поможет. По одной простой причине. На обработку сообщений всегда пишется тест. Не для проверки типа, а для того что бы быть уверенным — актор корректно обработает сообщение. На этом этапе сразу отсекаются ошибки типов сообщений. При чем AkkaTest позволяет как раз описать поведение акторов, т.е. например актор обязан получить сообщение обработать его.
Не просто может, а именно обязан получить.
Но если не писать тестов вообще, то конечно типы помогут в таких случаях.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал. Таких надо ссаными тряпками гнать из професии.
Умолчу уже о том, что писать систему (на важно на чем) без тестов это жесть и само по себе существенно снижает ценность типизации вызовов. Т.к. типизация сообщений (применительно именно к Акка конечно же) сама по себе может проверить лишь малую часть кода.
И она не стоит того, чтобы городить огород.
P.S. Прошу обратить внимание, что речь не про сферического коня «статика vs динамика». А конкретно про типизацию акторов в Акка. Потому что во всех других частях Акка с типами все отлично.
Опять же, я не могу представить себе ситуацию, что программист берет, выпиливает часть акторов, меняет сообщения и даже не проверят то что он сделал.
Я так понимаю, что речь идет про то, что когда приходится делать такой суровый рефакторинг, компилятор бы взял на себя часть работы — например, отказался бы компилировать места, где акторам отсылаются сообщения, в которых акторы больше не заинтересованы. Соответственно, при этом объем тестирования уменьшается.
Не думаю, что речь идет о том, чтобы вообще от тестирования отказаться.
И фишка в том, что объем тестирования это не уменьшит, т.к. все равно надо написать тесты на все сообщения получаемые актором. И в процессе этого дела я не представляю как можно пропустить что актор не обрабатывает нужное сообщение…
И в процессе этого дела я не представляю как можно пропустить что актор не обрабатывает нужное сообщение…
Думаю, что основная проблема не в этом. Допустим, у нас есть актор A, который обрабатывал сообщения x, y и z. После рефакторинга он стал обрабатывать сообщения x, v и w. Соответственно, тестами мы проверим, что актор A эти сообщения обрабатываются. Ну и кроме как тестами мы это никак не проверим.
Но, в большой программе с актором A могут взаимодействовать акторы B, C и D. Полагаю, проблема, с которой столкнулся PHmaster в том, что нужно вручную проверять, отсылают ли B, C и D сообщения y и z. Если отсылают, то нужно править код. И тут вопрос упирается в количество и качество интеграционных тестов.
Еще хуже ситуация может быть, если какой-то актор N в run-time получает ссылку на актора, которому можно отослать сообщение y. И заранее нельзя сказать, будет ли это актор A или актор AA. После рефакторинга актора A актор N продолжит успешно взаимодействовать с актором AA, но у него возникнет облом с новым актором A. Но это может выясниться спустя несколько месяцев после рефакторинга.
Т.е. теоритически понятно, про какие преимущества говорит PHmaster, но интересно, почему в нашей практике это не было проблемой. При том, что приложения жили и развивались по десятку лет и рефакторились неоднократно.
Да, все так. Юнит-тесты проверяют работоспособность одного отдельно взятого актора, интеграционные тесты покрывают некоторые варианты взаимодействия нескольких акторов, но тестами нельзя покрыть все возможное варианты взаимодействий в настоящей и будущих версиях активно развивающегося приложения. Помимо того, что один разработчик не способен постоянно держать в голове всю структуру достаточно маштабной системы, — таких разработчиков в проекте может быть много, они могут неоднократно меняться, их уровен знаний и осведомленности может сильно различаться. Тесты, документация — все это хорошо и полезно, но почему к этим инструментам не добавить еще и строгую типизацию? Да, она одна не решает сразу всех проблем, она лишь помогает решить некоторые из них более эффективно и менее затратно. Добавляет больше контроля над процессом разработки, и уменьшают количество способов выстрелить себе в ногу.
Да, у меня все так и начиналось: стройно и элегантно. Но потом один актор разбивается на несколько подакторов, сообщения транслируются по цепочке и обрабатываются уже не тем актором, кому изначально отосланы. И кому они теперь "принадлежат" — становится не совсем понятно. В общем, может мне просто не хватило времени, чтобы упорядочить и наладить свой рабочий процесс разработки в этой парадигме.
Если с течением времени происходит изменение логики работы producer-а (он разбивается на группу акторов), то тогда есть два варианта:
1. Это сказывается на интерфейсе взаимодействия. Т.е. вместо acquire и release появляются другие запросы. Это элементарная ситуация, она отлавливается самим компилятором.
2. Интерфейс взаимодействия не меняется (т.е. остаются acquire и release), но теперь consumer-у нужно взаимодействовать с одним актором для выполнения acquire и с другим актором для выполнения release.
Мне не кажется, что проблемы второго случая имеют отношение к достоинствам или недостаткам модели акторов. И что преодоление таких проблем должно контролироваться системой типов и проверяться в compile-time. Ибо здесь, по сути, мы имеем проблемы с владением actor_reference, а не проблемы типов сообщений.
Суть акторов, что любой актор может послать любое сообщение любому актору и только актор сам решает, может он обработать это сообщение или нет. Это позволяет строить очень гибкие решения.
Я с вами полностью согласен, но они одновременно и гибкие и не безопасные. Актор это скажем человек, вы можете пасти его на поле и кормить сеном, хотя он будет отказываться), но я думаю вам все же нужно знать что это человек и как с ним взаимодействовать — т.е. его тип и связанный с типом интерфейс.
Иначе у вас получится обычный ООП с дерганьем методов и сильной связанностью. Поэтому вам и Future больше подходит для задач чем акторы.
ООП и акторы это концепции очень схожие и да я хочу что бы у меня была сущность ведущая себя как актор но предоставляющая такие же гарантии как интерфейсы в ООП(дерганье методов).
Писал несколько проектов на Akka, вообще ни разу не сталкивался с неправильной инициализацией акторов и всеми теми проблемами что вы описали. Даже новички так не ошибались в коде.
Ну что ж тут я с вами спорить не буду, спасибо за "апелляцию к авторитету".)
2) Таких гарантий нет ни в одном приложении. Это все зависит только от разработчика. Он может забыть что угодно. В одном месте добавил метод, в другом забыл его «дернуть».
Не совсем об этом, речь о том что вы передали сообщение а оно не дошло, т.е. по аналогии вызвали метод а он не был вызван, причем по какой то внешней причине. Скажем вы в реализации без актора вызвали метод который проверяет является ли данный запрос мошенническим и вы будете уверены что он будет вызван, т.к. вы можете исходя из кода(т.к. это цепочка вызовов) быть уверены что на проде будет вызываться конкретная последовательность методов. Если у вас этот процесс реализован как передача сообщений от актора к актору таких гарантий нет, понятно — у вас могут быть и тесты и хорошие разработчики и тестировщики, но это дополнительная сложность, которая может привести к ошибке, и я уверен такие ошибки периодически будут встречаться вне зависимости от вашего уровня организации работы.
3) Таких гарантий тоже нет ни в одном приложении, см п 2.
Есть гарантия что если вы вызвали метод то он выполнится и есть гарантия какой будет конкретно вызван метод, понятно что только если ваш язык имеет достаточный уровень проверки типов, как в Scala.
В целом хорошо описано тут: http://stew.vireo.org/posts/I-hate-akka/
Почитал. Первые две проблемы (с отсылкой Foo вместо Foo() и с подпиской актора на eventStream без его ведома) — это какая-то специфика Scala и Akka. Не стоит распространять эти аргументы на Модель Акторов вообще. В частности, у нас в SObjectizer и C++ подобные фокусы крайне сложно будет повторить.
Возможно я не везде ясно выражался, но в начале уточнил что у меня перечисленные вопросы возникли именно с Akka. В общем то это проблема не то что бы Akka+Scala а отсутствия проверки типа отправляемого сообщения. Отличие Scala лишь в том что одно имя означает близкие по сути но разные сущности. В самом простом виде эта проблема заключается в том что вы посылаете другому актору тип A но тот не имеет обработчика для этого типа(т.е. данное сообщение вообще не должно посылаться данному актору).
По поводу контроля типов: ведь проблема того, что актор не обрабатывает сообщения типа A ничем не отличается от той проблемы, что актор-получатель по каким-то причинам решил не обрабатывать конкретное сообщение типа A. Т.е. пульнули сообщения актору, а дошло оно или нет, будет ли обработано, если дошло или не будет — вот это вот все фундаментальная особенность акторов. Понятно, что не везде это подходит. Но там другие подходы к concurrency просто используются.
Согласен нужно было уточнить что я говорю все же о Akka.
Касаемо:
По поводу контроля типов: ведь проблема того, что актор не обрабатывает сообщения типа A ничем не отличается от той проблемы, что актор-получатель по каким-то причинам решил не обрабатывать конкретное сообщение типа A...
Все таки я вижу отличие в одном случае это часть логики — т.е. мы так задумали что сообщение не обрабатывается, в другом это не ожидаемо(не корректное поведение).
Все таки я вижу отличие в одном случае это часть логики — т.е. мы так задумали что сообщение не обрабатывается, в другом это не ожидаемо(не корректное поведение).
Тут мне лично не понятно, чьи именно это проблемы: отправителя или получателя.
Вряд ли получателя, поскольку если ему отсылает кто-то сообщение, в котором он не заинтересован, то сообщение просто теряется.
Ну а отправителю, повторюсь, не важно из-за чего именно его сообщение потеряно: не тот агент или где-то защита от перегрузки сработала.
Из чего-то более толкового можно посмотреть вот это: How To Make An Infinitely Scalable Relational Database Management System (RDBMS)
Или вот это: REST Commander: Scalable Web Server Management and Monitoring.
С проектами, в которых наш SObjectizer использовался сложнее: это все были закрытые коммерческие разработку и я не уверен, что могу какие-то подробности озвучивать.
Ну попробует Erlang-овый процесс поделить на ноль, ну упадет, Erlang-овая виртуальная машина почистит мусор, супервизор создаст упавший процесс заново и все. А вот в C++ попытка деления на ноль, скорее всего, убьет все приложение, а не только того агента, в котором ошибка произошла.
Я вот тут подумал, а почему бы не построить модель акторов на базе родительского процесса + по процессу на каждого актора? Это даёт нам возможность применять подход «let it crash» — супервизор точно так же сможет детектить погибших акторов и перезапускать их. Более того, мы получаем более защищённую модель поведения — акторы уже не смогут «ненароком» что-то писать\читать из общей памяти — им придётся использовать исключительно протокольный обмен сообщениями.
Да, будут определённые накладные расходы на запуск процессов и память под них, но в ряде случаев они не столь критичны. Если количество акторов будет в пределах пары десятков — эта модель вполне может жить.
Речь вот о чем: вы можете сделать сложное приложение с использованием Модели Акторов, которое будет состоять из нескольких самостоятельных процессов, взаимодействующих через IPC. Каждый процесс будет, фактически, представлять из себя актора.
По сути, это будет то же самое, что происходит сейчас в Erlang-е. Только в Erlang-е независимые процессы работают в рамках VM (если речь про одну VM на одной ноде). А тут независимые процессы будут работать в рамках ОС.
Я же хотел подчеркнуть, что для такого подхода, наверное, не потребуется чего-то специализированного. Только какой-то IPC, который будет выполнять роль «почтовых ящиков». Ну а супервизоры делаются внешними средствами (как это и происходит с использованием того же runit-а в Unix-а).
Шишки, набитые за 15 лет использования акторов в C++. Часть I