Как стать автором
Обновить

Комментарии 5

Может невнимательно прочитал, если сообщение обрабатывается больше чем одним получателем, и все возвращают результат, то ResultMessage будет содержать все результаты?
Когда делал свою реализацию обмена сообщениями (правда только в рамках процесса, но с возможностью общения между доменами), то в качестве результата отправки сообщения делал объект который позволяет получить набор из любого количества ответов, с указанием от какого из обработчиков ответ получен.
Еще показалось удобным сделать подписку на окончание обработки сообщения. Пример применения, появился файл в каталоге, отправили сообщение, кто-то обработал файл, получаем сообщение от роутера что все получатели сообщений закончили работу, и можем удалить/заархивировать файл.
Если будет отправлено несколько одинаковых сообщений-результатов, на тип которых подписан отправитель, то он получит только одно — первое пришедшее. Дело в том, что в противном случае не известно сколько всего ждать ответов и как долго нужно хранить promise в коллекции.
В приведенном вами примере, если обработка выполняется только одним актером, то он как раз и отправит это уведомдение об окончании работы.
Так роутер же знает количество подписчиков, значит можно реализовать и ожидание пока все не ответят, и отваливание по таймауту. Хотя я рассматриваю больше с позиции издатель подписчик, а акторы могут в ответ на сообщение создать свое, и ожидание ответов ненужная опция получается.
Да, роутер знает. Но, подписка на ответ (promise) хранится не на MessageRouter, а на MessageHub. Кроме того, MessageRouter может иметь устаревшую информацию о доступных актерах, например, кто-то уже мог отвалиться от сети, но таймаут, по которму удаляется маршрут, еще не наступил.
Я не говорю, что ваш случай «неправильный», просто объясняю, как сейчас сделано :)
Если вы имеете в виду, что сообщение о результате, должно быть отправлено только при получении определенного количества промежуточных сообщений, что-то типа map-reduce, то это можно сделать с помощью дополнительного актера и CorrelationId. У меня был рабочий пример, но получается немного сложновато.
Ваш вопрос время от времени не давал мне покоя :) Возможность получения ответа на broadcast-сообщение действительно полезная вещь и имеет место быть.
И, вот, когда я уже подошел вплотную к реализации такого вида подписки, я понял, что данная фича уже реализована. Дело в том, что broadcast-сообщение рассылается простым перебором всех известных раутеру подписчиков. Список подписчиков нам (может быть легко) доступен. Причем, в kino есть возможность отправить сообщение конкретной ноде, зная ее ID. То есть, мы параллельно отправляем сообщение каждой известной нам ноде и ждем от всех них ответа. Также, у нас появляется возможность знать, какая конкретно нода не ответила.
Спасибо за вопрос!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории