Как реализовать непрерывную обработку очереди документов?

[Gandliar]

Доброго дня!

Реализую сейчас функционал работы телеграм бота на лотусе.
Прошу совета по оптимальному решению отправки сообщений в телеграмм.
Пока думаю для отправки сообщений создать отдельную базу, в которую будут ложиться ответы для отправки в телеграмм.
И каким то образом хочется чтобы эти ответы максимально быстро отправлялись.
Причем возможны какие то ошибки, к примеру недоступность сети, соответственно как только сеть восстанавливается - отправка нужна немедленно.
Может кто сталкивался с реализацией обработки непрерывной очереди документов, и что то посоветует.

 

[aameno2]

мне кажется вы изобретаете очередь сообщений)

 

[Gandliar]

мне кажется вы изобретаете очередь сообщений)

Где посмотреть готовый вариант на лотусе?

 

[aameno2]

Это из области фантастики кмк. Кафка, кролик. Выбирайте на вкус

 

[Gandliar]

По итогу сделал 2 агента по расписанию, запускающиеся каждые 5 минут, которые вызывают функцию из библиотеки.
Функция в течение 5 минут опрашивает вид и в случае наличия в нем документов их обрабатывает.

 

[aameno2]

Костыль, простите. Асинхронность и события гораздо лучше. Внешняя "шина" и дергать агентов.

 

[VladSh]

Ссылка скрыта от гостей

лучше. У нас процесс выполнения запросов на нём работает. Вид с PRIORITY_HIGH проверяется раз в 10 секунд, запуская агент, который идёт по виду и обрабатывает документы.

 

[Gandliar]

Костыль, простите. Асинхронность и события гораздо лучше. Внешняя "шина" и дергать агентов.

Непонятно, как сделать без костыля.
Для этого мне надо отловить событие помещения документа в базу, это если асинхронно - непонятно как сделать, посылать почтой? Почтой тоже не уверен в скорости.
Либо при помещении документа в базу - вызывать агент, который будет отправлять, Это сэкономит процессорное время при малой нагрузке, а при большом количестве сообщений - нет. И добавит необходимость делать механизм блокировок.
И как быть если пропала связь или возникла ошибка.
Сейчас я сделал вариант из нескольких баз. В первую поступают сообщения, агенты мониторят наличие сообщений в виде для обработки, обрабатывают, если нашелся документ, и помещает в базу отправки. В базе отправки агенты отправляют все что поступило в базу.

Есть какие то идеи, как сделать лучше?

 

[savl]

DOTS еще можно, но там с событийностью свои траблы. При больном потоке может падать задача и сервер за собой тянуть.
Jaddin - это самописная серверная задача. По сути тот же агент, но уровень другой. Да, работает самостоятельно и пошустрее.

Глобально, по правильному, тут нужна действительно внешняя шина или менеджер очередей.
Из лотуса требуется только в очередь сообщение отправить: httpRequest или запись агентом, уже не важно, всего лишь транспорт.
А дальше там уже вся магия: отправка, ожидание появление канала, повторная отправка при сбое и так далее и тому подобное - другой слой.

 

[aameno2]

Есть какие то идеи, как сделать лучше?

@savl собственно описал.
Городить очередь в лотусе это странно. Поэтому у вас появляется внешняя шина, которая общение с очередью делает за лотус.
В шину вы кидаете нужное вам сообщение. Я обычно кидаю еще callback url.
А очередь за вас делает всякие прелести, типа маршрутизации, повторной отправки и т.д.
Примеров на той же яве выше крыши.
Для очень сильных духом - C API. Но поверьте, там очень страшно)
Upd.
Модуль внешней шины, при правильной архитектуре, пишется один раз только. Вне зависимости от предающихся данных.

 

[Gandliar]

Спасибо огромное!
Jaddin - буду пробовать

Если я правильно понял, то глобально мой подход правильный, однако для промышленной реализации лучше:
1. Использовать Java (для скорости и большей гибкости) для обработки очереди
2. Использовать для обработки очереди отдельный сервер (как внешнюю шину) для скорости
3. На отдельном сервере использовать для запуска java не лотус
4. Использовать для хранения очереди бд не лотус (для скорости)

Вопрос - при прочих равных агент обработки лотус-документов на java будет работать быстрее? Насколько в % может быть прирост производительности?

 

[aameno2]

Почти. Вы сами говорите, что хотите непрерывную обработку, но при этом у вас в выборе только агент в 5 минут.
Отдельный сервер - по вашим хотелкам и возможностям. Нагрузка на шину будет никакая.
На чем вы ее напишите, тоже не важно. У меня шина на плюсах.
Хранение очереди - в очереди. Там своя логика.
Скорость - ну тут вы смотрите, ваша же обработка на сервере) Очередь только для доставки в нужное место

 

[VladSh]

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

Почти всё правильно.

Jaddin - это серверная задача; суть её для вашей задачи в том, чтобы запускать агент через определённый промежуток времени. Эта часть написана на Java. В старой версии, 10-летней давности, что у нас, там в коде нужно было самому поставить количество миллисекунд, через которое выполнять действие (в нашем случае - запускать агент). В последних версиях не знаю, возможно там это уже встроено, и нужно просто где-то в конфиге указать путь к базе, имя агента и период запуска. Раньше на гитхабе лежали все исходники, и можно было их глянуть, теперь почему-то я их не вижу...
Использовать Jaddin, по моему, неплохое решение для Domino. Особенно в условиях отсутствия ресурсов на внешние шины и опыта работы с ними. Тем более, HCL включила Jaddin в свой магазин приложений, а они просто так этого не делают. То есть уровень поддержки и самого решения достаточно высок.

В принципе в Jaddin можно не запускать агент, а написать полностью обработку, которую выполняет ваш агент. Но если это потянет подключение дополнительных jar'ов, то может вылиться в серьёзные проблемы. Т.е. Jaddin'у лучше оставить простую задачу - запускать агент. А уже в нём писать свою логику.

Только агент на Java - это очень спорный вопрос. Зачем именно на Java? Jaddin'у всё равно, какой агент запускать. Наоборот, LS агент будет запускаться и работать гораздо быстрее, не будет проблем с выделением и возможными утечками памяти. Как по моему, если есть возможность не использовать Java в агентах, надо её не использовать.
Если рассматривать вопрос на будущее, когда HCL перепишут весь движок на Java (как они собирались), вот тогда ситуация с Java и LS поменяется с точностью наоборот. Но это дела настолько далёкого будущего, что не факт, что это вообще когда-нибудь случится.