Отложенная дерегистрация кооперации

[Дмитрий Николаевич]

Добрый день.

Начал использовать вашу библиотеку (v.5.6), возник следующий вопрос.

Дерегистрация одной кооперации начата агентом из родительской кооперации, но фактически ее действие нужно приостановить до определенного момента.

При завершении окружения, есть механизм stop guard - ов, который позволяет эту проблему решить, но тут речь именно об уничтожении одной дочерней кооперации.

[Yauheni Akhotnikau]

Доброго дня!

Дерегистрация кооперации -- это операция, меняющаяя привязку агентов в SOEnv. Т.е. после завершения вызова deregister_coop агенты лишаются возможности получать новые сообщения. Все, что они могут сделать -- это доработать то, что уже ждет их в очередях и все.

Мне даже сложно сейчас представить, можно ли как-то поменять эту логику и добавить возможность "отложенной дерегистрации".

В принципе, между shutdown и deregister_coop есть очень важное отличие: в том месте программы, в котором инициируется shutdown можно не знать, что происходит внутри других частей программы. Поэтому здесь stop_guard восстребован. Но вот в случае с deregister_coop ситуация должна быть иная: тот, кто дерегистрирует кооперацию уже знает, что она больше не нужна. Ведь если бы она была нужна, то ее и не требовалось бы дерегистрировать.

Может расскажите о своей ситуации подробнее? Вдруг там есть какой-нибудь другой способ достичь нужного вам результата.

[Дмитрий Николаевич]

Да, конечно. Проблема следующая. Есть, например, агенты А, агенты Б, агенты С. Цепочка А->Б->C. Агент А  - некий ресивер. который принимает пачку из K сообщений, агенты Б и С работают на уровне сообщений, понятие пачки скрыто за ресивером

Соответственно, если я хочу убрать кооперацию с агентом А, тот что является ресивером, то для обеспечения консистентности необходимо, чтобы кооперация  с агентом А уничтожилась только тогда, когда  вся текущая пачка из К сообщений обработалась.

Если конкретно, это вызвано работой с rabbitmq (его клиент на агенте А), в котором часто для уменьшения накладных расходов такскают так называемые батчи, пачку сообщений, и amqp - ый ack работает на уровне вот этих батчей.

пятница, 9 августа 2019 г., 12:04:09 UTC+3 пользователь Yauheni Akhotnikau написал:

[Yauheni Akhotnikau]

Мне кажется, что вам здесь нужно агента А как-то дополнительно уведомлять о том, что вся работа сделана и он может самоубиться.

Например, можно попросить агента C прислать какое-то уведомление агенту А когда пачка обработана. Ведь вы же все равно как-то специально определяете момент завершения обработки пачки K дабы разрешить дерегистрацию A.

Можно даже использовать подход, при котором C вообще не нужно ничего самому отсылать. Делается это как-то вот так:

class completeness_notificator_t {

   const so_5::mbox_t m_target; // Это и есть mbox агента A.

public:

   completeness_notificator_t(so_5::mbox_t target) : m_target{std::move(target)} {}

   ~completeness_notificator_t() {

      so_5::send<work_completed>(m_target);

   }

};

После чего добавляете объект такого типа в сообщение с пачкой K. Когда это сообщение будет обработано (или проигнорировано), то агенту A автоматически будет отослано сообщение work_completed.

PS. На самом деле у completeness_notificator_t надо бы запретить копирование, а в деструкторе проверять m_target на пустоту и ловить исключения на всякий случай. Но принцип остается таким же.

[Дмитрий Николаевич]

Спасибо, идея вроде понятна. Еще такой момент, который хочется уточнить.

Вы писали: "Все, что агенты могут сделать -- это доработать то, что уже ждет их в очередях и все.". Есть  агент А, агент Б. Они принадлежат одной кооперации.

Допустим есть следуюая цепочка вызовов:

1. Агент А шлет сообщение угенту Б ( в его direct_box()).

2. Кто-то делает вызов deregister_coop для кооперации, которой принадлежат А и Б

3. Агент А шлет сообщение угенту Б ( в его direct_box()).

3. Б получит сообщение, высланное на шаге 1.

4. Б не получит ведь сообщение, высланное на шаге 3 ?

пятница, 9 августа 2019 г., 12:46:04 UTC+3 пользователь Yauheni Akhotnikau написал:

[Yauheni Akhotnikau]

> 4. Б не получит ведь сообщение, высланное на шаге 3 ?

Если шаг 2 произошел уже после завершения шага 1 и строго до шага 3, то не получит.

Не должен, по крайней мере. Если получит, значит это баг, который нужно исправить.

[Дмитрий Николаевич]

Спасибо за оперативность.

пятница, 9 августа 2019 г., 13:06:02 UTC+3 пользователь Yauheni Akhotnikau написал:

[Yauheni Akhotnikau]

On Fri, Aug 9, 2019 at 1:14 PM Дмитрий Николаевич <sazo...@gmail.com> wrote:

Спасибо за оперативность.

Не всегда это получается, но стараемся.

Если сможете затем поделиться своими впечатлениями от SObjectizer-а (что понравилось, что не понравилось, чего не хватило, чего было слишком много), то нам это поможет сделать свой продукт лучше.

[Дмитрий Николаевич]

Да, конечно.

пятница, 9 августа 2019 г., 13:16:10 UTC+3 пользователь Yauheni Akhotnikau написал: