Комментарии 4
И нам бы хотелось, чтобы когда в очереди уже стоит 900 сообщений msg_status новое сообщение msg_result вставало не в конец очереди, а в самое ее начало.
Насколько это корретно в общем случае? Нарушается последовательность событий, и событие msg_result произойдёт "в будущем" относительно msg_progress "в прошлом", но порядок получения событий не соотвествует (как я понимаю) порядку их возникновения.
Я могу себе представить пример, когда msg_progress уже неважны после получения msg_result и по сути отбрасываются приёмником. Но тогда, msg_result имеет ещё и семантику отмены (cancellation) предыдущих сообщений.
Есть ли пример, когда это не выполняется, т.е. когда msg_progress всё ещё важны, даже после получения msg_result ?
Насколько это корретно в общем случае?
Приоритетная обработка и общий случай — это вообще плохосовместимые понятия. Как я говорил, в SO-4 была поддержка приоритетов, но на практике пользы от нее не было. За исключением, может быть, одного или двух случаев.
Так что, как только возникают приоритеты, то мы практически сразу начинаем говорить о каких-то специальных ситуациях. ИМХО.
Есть ли пример, когда это не выполняется, т.е. когда msg_progress всё ещё важны, даже после получения msg_result?
В статье приведен вырожденный случай, который должен быть максимально понятный.
На практике для status и result, скорее всего, первый же result должен был бы сделать неактуальными все предшествующие status-ы. И нам бы, скорее всего, потребовалась бы очередь, которая бы не только ставила бы result на первое место, но и выбрасывала бы предыдущие status-ы, которые уже были в ней.
Но на той же практике ситуация могла бы быть и посложнее. Например, агент, который ждет result и status, инициирует не одну операцию, а 100500. И на каждую из начатых операций он ждет result-ы и status-ы. А сопоставляет пришедшие сообщения с ранее начатыми запросами по каким-то ID внутри сообщений. Тогда в очереди может стоять 900 status-ов для запросов с разными ID и поступление единственного result-а инвалидирует только чать этих статусов.
Решаться это может тем, что агент держит у себя словарь начатых запросов и при получении status-а проверяет наличие записи в этом словаре. Если записи нет, то либо result уже был получен. И status можно легко проигнорировать.
Если же говорить о применении приоритетов на практике, то могут быть и ситуации, которые не связаны со status/result вообще. Скажем, есть агент, который обрабатывает поток заявок. Часть этих заявок идут от клиентов, которые прямо сейчас находятся в он-лайне, а часть заявок выдается какой-то системой по расписанию. Поскольку мы хотим, чтобы клиенты в он-лайне обслуживались максимально быстро, мы можем поднять приоритет для тех сообщений, которые касаются заявок этих клиентов. Тогда как приоритет для сообщений, касающихся заявок от автоматизированной системы будет понижен.
Так что, как только возникают приоритеты, то мы практически сразу начинаем говорить о каких-то специальных ситуациях. ИМХО.
Тут я полностью согласен.
Часть этих заявок идут от клиентов, которые прямо сейчас находятся в он-лайне, а часть заявок выдается какой-то системой по расписанию.
Хороший пример. В данном случае "приоретизация" сообщий от онлайн-клиентов — это скорее техническое решение "как?" более общей постановки вопроса, что "запросы от онлайн-клиентов должны, по возможности, обрабатываться раньше, чем от офлайн-автоматики".
Чисто акторное тоже техническое решение, которое напрашивается, это актор-сортировщик, к которому стекаются все заявки, а он уже внутри себя раздаёт их на обработку: если есть онлайн-заяки, отдаём на обработку их, иначе — офлайн.
Чисто акторное тоже техническое решение, которое напрашивается, это актор-сортировщик, к которому стекаются все заявки, а он уже внутри себя раздаёт их на обработку
Да, практика показывает, что многие такие вещи можно разрулить при помощи пары collector-performer, где collector набирает сообщения пока performer занят, а затем выдает performer-у наиболее актуальную работу на данный момент.
Собственно, это одна из причин, по которой изначально в SO-5 поддержки приоритетов вообще не было.
Но collector-performer — это все-таки два агента. Требует больше работы и сопровождать такой код может быть сложнее, особенно когда на проект приходят новые люди и им нужно разобраться в разделении логики между агентами.
Не хочется ждать в очереди? Напишем свой диспетчер для SObjectizer с приоритетной доставкой