search

BITERP / PinkRabbitMQ

Внешняя Native API компонента для взаимодействия с RabbitMQ из 1С
MIT License
264 stars 107 forks source link

Добавить возможность уведомлять 1С о приходе сообщения через HTTP сервис #2

Closed Begemoth2 closed 4 years ago

Begemoth2 commented 5 years ago

Подробности см. https://partners.v8.1c.ru/forum/t/1846210/m/1846518

ripreal commented 5 years ago

Идея интересная. Я попробую ее реализовать. Конечно есть и именусы такого подхода:

MinimaJack commented 5 years ago

Можно описание подробнее, не у всех есть доступ к форуму...

Begemoth2 commented 5 years ago

@MinimaJack Цитирую предложение с партнерского форума "Вы не рассматривали написание прослойки для обмена вашей компоненты с 1С через её http-сервисы (вместо пулинга очереди в цикле)? Например, компонента поднимает прокси и начинает слушать кроля с одной стороны и общаться с 1С с другой (или использовать её http-сервис как push-уведомление)."

MinimaJack commented 5 years ago

Спасибо. Идея так себе - теряется смысл в компоненте, так можно и сообщения push-ить в сервис из прослойки.

Begemoth2 commented 5 years ago

@MinimaJack Нет не теряется, http работает медленнее AMQP (и медленная установка соединения), т.е. тут предложение именно в том, чтобы использовать http-сервис только для того, чтобы "разбудить" 1С (сказать ей что пришли сообщения), а дальше 1С уже через компоненту по протоколу AMQP начинает их массово и параллельно забирать (а отправка так и остается через компоненту).

Т.е. это всего-лишь средство не держать в 1С все время активное соединение которое слушает кролика, а "будить" 1С по внешнему событию

MinimaJack commented 5 years ago

@Begemoth2 Что делать если будет приходить много сообщений?? Спамить 1С вызовами? Как контролировать что данные из очереди все еще забираются регл.заданием? Что делать тем у кого все на поддержке?Кто будет мониторить http-демон? Зачемммм....

Установка соединения что http, что amqp - практически идентична, большая часть времени сожрет tcp-layer. Весь смысл в backpressure и pull-подходе, когда данные забираются с той скоростью с которой могут быть обработаны. А так получится дикая смесь: ни то, ни сё.

p.s. Текущие сервера без особых проблем переваривают поддержание десятки тысяч активных соединений. p.p.s Как по мне решается надуманная проблема...

Begemoth2 commented 5 years ago

@MinimaJack При текущем подходе (который реализован в компоненте) для того, чтобы новые сообщения приходили быстро (сразу после появления в очереди) на сервере 1С должен постоянно висеть сеанс (например фонового задания) в котором выполняется ожидание в методе BasicConsumeMessage (как только сообщение приходит, оно получается и управление передается в код 1С).

Этот подход (вечно висящее соединение) приводит к определенным проблемам, как минимум конфигурацию сложно обновлять ;-)

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

dobromyslov commented 5 years ago

Я считаю, что добавлять это в текущую библиотеку - плохая идея. Если нужно будить 1С по HTTP - каждый сам может написать микросервис на любом языке, подписать его на очередь RabbitMQ и делать всё, что угодно с 1С через HTTP. А PinkRabbitMQ должна работать исключительно с RabbitMQ и не более того.

salsa-dev commented 5 years ago

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

Если кому известны такие решения, интересно ознакомиться.

В целом, подход PULL обоснован, но, как всегда, есть пограничные случаи, когда PUSH очень нужен.

salsa-dev commented 5 years ago

Нашёл возможное решение https://docs.celeryproject.org/en/latest/getting-started/first-steps-with-celery.html#first-steps

ripreal commented 4 years ago

Не актуально в рамках компоненты. Закрываю