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

Gandliar

Gandliar

Lotus Team
16.02.2004
571
26
BIT
170
Доброго дня!

Реализую сейчас функционал работы телеграм бота на лотусе.
Прошу совета по оптимальному решению отправки сообщений в телеграмм.
Пока думаю для отправки сообщений создать отдельную базу, в которую будут ложиться ответы для отправки в телеграмм.
И каким то образом хочется чтобы эти ответы максимально быстро отправлялись.
Причем возможны какие то ошибки, к примеру недоступность сети, соответственно как только сеть восстанавливается - отправка нужна немедленно.
Может кто сталкивался с реализацией обработки непрерывной очереди документов, и что то посоветует.
 
Это из области фантастики кмк. Кафка, кролик. Выбирайте на вкус
 
  • Нравится
Реакции: savl
По итогу сделал 2 агента по расписанию, запускающиеся каждые 5 минут, которые вызывают функцию из библиотеки.
Функция в течение 5 минут опрашивает вид и в случае наличия в нем документов их обрабатывает.
 
Костыль, простите. Асинхронность и события гораздо лучше. Внешняя "шина" и дергать агентов.
 
Ссылка скрыта от гостей
лучше. У нас процесс выполнения запросов на нём работает. Вид с PRIORITY_HIGH проверяется раз в 10 секунд, запуская агент, который идёт по виду и обрабатывает документы.
 
aameno2 сказал(а):
Костыль, простите. Асинхронность и события гораздо лучше. Внешняя "шина" и дергать агентов.
Нажмите, чтобы раскрыть...
Непонятно, как сделать без костыля.
Для этого мне надо отловить событие помещения документа в базу, это если асинхронно - непонятно как сделать, посылать почтой? Почтой тоже не уверен в скорости.
Либо при помещении документа в базу - вызывать агент, который будет отправлять, Это сэкономит процессорное время при малой нагрузке, а при большом количестве сообщений - нет. И добавит необходимость делать механизм блокировок.
И как быть если пропала связь или возникла ошибка.
Сейчас я сделал вариант из нескольких баз. В первую поступают сообщения, агенты мониторят наличие сообщений в виде для обработки, обрабатывают, если нашелся документ, и помещает в базу отправки. В базе отправки агенты отправляют все что поступило в базу.

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

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

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

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

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

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

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

В итоге вырисовалась вот такая схема

Из телеграмм бота сообщения поступают в базу "Бот"
База "Бот" пишет сообщения в базу "Входящие" и в базу "Лог"
В базе "Входящие" постоянно запускается обработчик 1, который обрабатывает сообщения, ответ записывает в базу "Исходящие" и в базу "Лог". После записи из базы "Входящие" удаляет (removePermanently)
В базе "Исходящие" постоянно запускается обработчик 2, который отправляет сообщения в телеграмм бот и пишет в базу "Лог", после отправки из базы "Исходящие" удаляет (removePermanently).

Таким образом, постоянно запускающийся обработчик можно реализовать на
1. Jaddin + запуск агента обработчика
2. Jaddin + код обработчиков на java
3. Сейчас реализовано на двух агентах по расписанию (обработчик запускается непрерывно в цикле)

Работает визуально как ожидается, пишешь сообщение в телеграмм бот, моментально приходит ответ.

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

Мои предшественники писали такую штуку, чтобы если сервер обработки не текущий, то пытаемся достучаться до рабочего, и если нет доступа, то отмечаем это где-то в профайле. И дальше вычитываем ещё одну настройку "через какое время недоступности текущий сервер будет считаться сервером обработки". И там была ещё одна настройка - порядок серверов, на которых переключать нагрузку при недоступности сервера обработки. Если время подходит, а связи с сервером обработки, указанном в настройках нет, то первый сервер из порядка серверов прописывает себя в настройку "сервер обработки", и Jaddin'ы начинают запускать агенты на этом сервере.
Но сейчас оно так не работает. Ребята говорят, что были проблемы с этим механизмом, - неоднозначно, сервер действительно упал, или просто нет с ним связи, и т.д. И сейчас они, в случае выхода из строя сервера обработки, меняют эту настройку на нужном сервере вручную.
То есть сейчас Jaddin'ы работают на всех хабах, но по сути ничего не делают, кроме тех, что на сервере обработки.
 
бот для телеги писал как отдельное приложение
- как БД юхал sqlite: для регистрации связи номера телефона, чтобы контролировать включение в канал+группа (бот общался с клиентом)
- ботов на java куча, я юзал с
Ссылка скрыта от гостей
и longpolling
интеграцию с доминой не делал
в случае интеграции и общением с акками (бота), надо думать над хранением личных данных клиентов (как минимум - телефон)
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ