Что называется "пользуясь случаем" хочу ещё раз сказать спасибо авторам за SObjectizer. Прошло уже почти два года с момента той публикации, в которой мы описывали наше с ним знакомство и использование. И сейчас могу добавить, что наша система продолжает функционировать (ежедневно) и за это время ни разу не было обнаржуено каких-то багов в SObjectzer. Всё отлично работает. Более того добавление новой функциональности происходит легко, т.к. это всего-лишь добавление нового актора или корректировка существующего. Спасибо ещё раз )
Ну если говорить о «верхнем уровне»(интерфейс оператора, алгоритмы управления), то это два небольших безвентиляторных блока на базе Intel. А по сути «обычные компы», на которые мы установили Linux (ALT Linux).
Какой оверхед по коду?
Да вроде нет «оверхеда» какого-то особого. От использования акторов кода не становится больше, наоборот мне показалось, что логика выражается достаточно лаконично.
По крайней мере с использованием того API который предоставляет sobjectizer.
Тогда в продолжение темы, мысль о проблеме revocable_t сообщений с «защитой от переполнения»…
Мне кажется (с одной стороны) revocable_t сообщения в общем случае являются такими же сообщениями как и другие (хоть и могут устаревать уже находясь в очереди на обработку). Поэтому тут нет конфликта. По идее «разработчик» должен настраивать свои лимиты с учётом того, чтобы у него размера очереди хватало и на работу с revocable_t сообщениями
(условно для случая когда они не успевают устареть находять в очереди).
С другой стороны, как вариант, можно было бы добавить ещё одну (настраиваемую) политику обработки переполнения, при которой в случае невозможности поместить новое сообщение в очередь (или канал), происходит её чистка от «устаревших» сообщений. Т.е. прошлись по очереди, если встретили такой вид сообщений, проверили и удалили если устарело. И после этого, если место не освободилось, то реакция «как обычно». Конечно такая чистка может быть «дорогой операцией», но на то это и «отдельная настраиваемая политика обработки».
Может попробовать зайти с другой стороны? Со стороны обработчика агента?
Т.е. будет специальная функция подписки c проверкой устаревания
и специальный тип сообщений от которых нужно наследоваться
(содержащих в себе всё необходимое для проверки).
Что-то типа
struct my_timer_message:
public so_5::lifetime_message_t
{
...
}
А подписка:
st.lifetime_event( &MyAgent::on_timer );
внутри которой «прозрачным образом» пользовательский обработчик будет «обёрнут»
ещё одним предварительным обработчиком с провекой «устаревания»…
1. Реализация проверки актуальности каждого сообщения перед его обработкой. Позволяет получить отзывные сообщения, но ценой увеличения стоимости обработки любого сообщения. На синтетических бенчмарках это может означать потерю 7-8% производительности. Меня лично такой вариант вполне устроит, но с точки зрения маркетинга такая потеря не есть гуд.
Т.е. я видимо «за этот вариант». С точки зрения «не платить за то, что не используешь», может есть возможность сделать какую-то настройку для диспечера (параметр шаблона или ещё что-то такое)?
Потенциально, есть еще один вариант, который заточен именно под работу с таймерными сообщениями. ..
Мне кажется этот вариант «тяжелее» проверки флага перед обработкой. Я в целом видел реализацию как ваш старый проверенный способ — «монотонно растущий ID» у сообщений c проверкой перед доставкой.
Мне кажется проверка флага — не настолько дорогая операция, среди
общей массы «проверок» происходящих в среднестатистическом алгоритме.
РТ — это, так сказать, аспект или, если угодно, cross-cutting concern, и необязательно «пронизывает весь код».
Скорее всего мне не хватает опыта и знаний, посмотреть на проблему таймаутов более масштабно и соответственно решать её на другом уровне.
2. Если уж пошла такая пьянка, то то, что таймаут от одной операции прерывает другую операцию — это баг. А возможность такого развития событий — архитектурный просчет.
Вот это меня заинтересовало. Потому-что мне казалось, что без таймаутов вообще жить невозможно. Т.е. я с ними сталкиваюсь везде, начиная от API ОС и заканчивая алгоритмами в которых существует понятие «отмены операции» или «длительная операция». Поэтому мне очень интересна тема (без шуток), если существуют подходы которые позволяют архитектурно строить систему
условно говоря «без таймаутов». Не могли бы Вы указать какие-то «темы», «источники», «слова» что поискать на эту тему?
Вот как-то так, надеюсь, без обид.
Какие тут обиды. Вы расширяете мне кругозор. Спасибо )
Речь не обязательно о работе в реальном времени. Речь о любой работе (задаче) связанной с ожиданием (с таймаутами). Не знаю как везде, но как минимум в АСУ, «надёжное программирование» подразумевает, что любая операция должна быть конечной во времени. Поэтому чтобы вы не делали, что-либо включали/запускали
или что-то запрашивали, у Вас обязательно должен быть «защитный таймер» который гарантирует, что вы не застрянете на ожидании ответа «навечно». Т.е. у Вас по сути всегда, для какого-либо действия возникает необходимость произвести действие и засечь таймер (таймаут). И дальше либо «ответ»(обратная связь) придёт о том, что действие выполнено (успешно или нет), либо первее сработает таймер (таймаут) и вы будете выполнять какую-то обработку этой ситуации (например повторите попытку ещё несколько раз)… Тут-то и возникает описанная проблема, что если к Вам пришло вперёд сообщение о, допустим, успешном выполнении операции, то Вам сообщение от таймера уже не нужно. Точнее нужно, чтобы оно уже не приходило. Нужен механизм позволяющий отказаться от ранее заказанного таймера.
А eao197 как раз описал проблему. Что если механизм не гарантирует отказ от таймера (типа он уже в очереди, его оттуда не убрать), то почти гарантировано, что возникнет ситуация, когда Вы решите повторить попытку выполнить команду, засекаете вновь таймер, а сообщение приходит в следующее мгновенье, от старого таймера, потому-что оно уже было в очереди в этот момент…
Т.е. мне кажется, что при активной работе с таймерами (а они нужна практически всегда в реальном асинхронном взаимодействии, т.к. всегда должен быть защитный таймер на любую длительную операцию), отмена таймера (или игнорирование «старых» сообщений от таймеров) очень нужны и важны. И конечно, хочется чтобы это поддерживалось на уровне фреймворка.
Будет ли это механизм с маркированием каждого таймера или же с возможностью вытащить его из очереди на обработку, для меня как пользователя фреймворка не важно. Главное чтобы это было «незаметно» и в идеале не требовало от меня добавлять в свои сообщения доп. поля, по крайней мере явным образом.
Мы у себя в проекте пытаемся использовать SObjectizer. По началу действительно «не привычно», но за день-два написания кода привыкаешь и даже начинает нравиться )
Если Вы хотите склонировать репозиторий то «git clone» это и делает.
Никаких --bare Вам не надо.
Не совсем понял что такое у Вас потом «fossil repo open»,
но предполагаю, что это и есть «checkout».
Вообщем мне кажется Вы «немного» преувеличили «сложность и неинтуитивность». Максимум я вижу «я так привык».
Что называется "пользуясь случаем" хочу ещё раз сказать спасибо авторам за SObjectizer.
Прошло уже почти два года с момента той публикации, в которой мы описывали наше с ним знакомство и использование. И сейчас могу добавить, что наша система продолжает функционировать (ежедневно) и за это время ни разу не было обнаржуено каких-то багов в SObjectzer. Всё отлично работает. Более того добавление новой функциональности происходит легко, т.к. это всего-лишь добавление нового актора или корректировка существующего.
Спасибо ещё раз )
www.pgcon.org/2008/schedule/attachments/55_pgq.pdf
Да вроде нет «оверхеда» какого-то особого. От использования акторов кода не становится больше, наоборот мне показалось, что логика выражается достаточно лаконично.
По крайней мере с использованием того API который предоставляет sobjectizer.
Да похоже что так.
Тогда в продолжение темы, мысль о проблеме revocable_t сообщений с «защитой от переполнения»…
Мне кажется (с одной стороны) revocable_t сообщения в общем случае являются такими же сообщениями как и другие (хоть и могут устаревать уже находясь в очереди на обработку). Поэтому тут нет конфликта. По идее «разработчик» должен настраивать свои лимиты с учётом того, чтобы у него размера очереди хватало и на работу с revocable_t сообщениями
(условно для случая когда они не успевают устареть находять в очереди).
С другой стороны, как вариант, можно было бы добавить ещё одну (настраиваемую) политику обработки переполнения, при которой в случае невозможности поместить новое сообщение в очередь (или канал), происходит её чистка от «устаревших» сообщений. Т.е. прошлись по очереди, если встретили такой вид сообщений, проверили и удалили если устарело. И после этого, если место не освободилось, то реакция «как обычно». Конечно такая чистка может быть «дорогой операцией», но на то это и «отдельная настраиваемая политика обработки».
Т.е. будет специальная функция подписки c проверкой устаревания
и специальный тип сообщений от которых нужно наследоваться
(содержащих в себе всё необходимое для проверки).
Что-то типа
А подписка:
внутри которой «прозрачным образом» пользовательский обработчик будет «обёрнут»
ещё одним предварительным обработчиком с провекой «устаревания»…
Т.е. я видимо «за этот вариант». С точки зрения «не платить за то, что не используешь», может есть возможность сделать какую-то настройку для диспечера (параметр шаблона или ещё что-то такое)?
Мне кажется этот вариант «тяжелее» проверки флага перед обработкой. Я в целом видел реализацию как ваш старый проверенный способ — «монотонно растущий ID» у сообщений c проверкой перед доставкой.
Мне кажется проверка флага — не настолько дорогая операция, среди
общей массы «проверок» происходящих в среднестатистическом алгоритме.
Спасибо.
Скорее всего мне не хватает опыта и знаний, посмотреть на проблему таймаутов более масштабно и соответственно решать её на другом уровне.
Вот это меня заинтересовало. Потому-что мне казалось, что без таймаутов вообще жить невозможно. Т.е. я с ними сталкиваюсь везде, начиная от API ОС и заканчивая алгоритмами в которых существует понятие «отмены операции» или «длительная операция». Поэтому мне очень интересна тема (без шуток), если существуют подходы которые позволяют архитектурно строить систему
условно говоря «без таймаутов». Не могли бы Вы указать какие-то «темы», «источники», «слова» что поискать на эту тему?
Какие тут обиды. Вы расширяете мне кругозор. Спасибо )
или что-то запрашивали, у Вас обязательно должен быть «защитный таймер» который гарантирует, что вы не застрянете на ожидании ответа «навечно». Т.е. у Вас по сути всегда, для какого-либо действия возникает необходимость произвести действие и засечь таймер (таймаут). И дальше либо «ответ»(обратная связь) придёт о том, что действие выполнено (успешно или нет), либо первее сработает таймер (таймаут) и вы будете выполнять какую-то обработку этой ситуации (например повторите попытку ещё несколько раз)… Тут-то и возникает описанная проблема, что если к Вам пришло вперёд сообщение о, допустим, успешном выполнении операции, то Вам сообщение от таймера уже не нужно. Точнее нужно, чтобы оно уже не приходило. Нужен механизм позволяющий отказаться от ранее заказанного таймера.
А eao197 как раз описал проблему. Что если механизм не гарантирует отказ от таймера (типа он уже в очереди, его оттуда не убрать), то почти гарантировано, что возникнет ситуация, когда Вы решите повторить попытку выполнить команду, засекаете вновь таймер, а сообщение приходит в следующее мгновенье, от старого таймера, потому-что оно уже было в очереди в этот момент…
Т.е. мне кажется, что при активной работе с таймерами (а они нужна практически всегда в реальном асинхронном взаимодействии, т.к. всегда должен быть защитный таймер на любую длительную операцию), отмена таймера (или игнорирование «старых» сообщений от таймеров) очень нужны и важны. И конечно, хочется чтобы это поддерживалось на уровне фреймворка.
Будет ли это механизм с маркированием каждого таймера или же с возможностью вытащить его из очереди на обработку, для меня как пользователя фреймворка не важно. Главное чтобы это было «незаметно» и в идеале не требовало от меня добавлять в свои сообщения доп. поля, по крайней мере явным образом.
А то немного смутило вот это
Никаких --bare Вам не надо.
Не совсем понял что такое у Вас потом «fossil repo open»,
но предполагаю, что это и есть «checkout».
Вообщем мне кажется Вы «немного» преувеличили «сложность и неинтуитивность». Максимум я вижу «я так привык».
это нормально, а
«сложно и неинтуитивно»?