Компоненты для RabbitMQ для 1С и OScript

#1

@EvilBeaver и кстати встает вопрос - будем ли мы делать платной компоненту для RabbitMQ или выкатим её в OpenSource.

Или я по другому задач вопрос - если мы выкатим компоненту интеграции, сколько котрибьюторов мы привлечем если она на С++ и будет ли полезно @pbazeliuk, если у него C#.

Применительно к OScript - есть второй заяц. В сфере появления активности по NuGet пакетам в oscript.io и продолжения работы по OScript Web Template - нам в перспективе понадобится интеграция на стороне сервера Oscript Web приложения. И с учетом появления докера запуск сайта полностью на oscript выглядит так

docker-compose up -d 

web:
   --name: web-context
   --image: nginx-alpine
   --volume: ./nginx-conf
server
  --name:: web-server
  --image: oscript-alpine
  --volume: ./oscript-web-application
db
  --name: database
  --image: postgresql-alpine
  --volume: /srv/database
amqp
  --name: rabbbit-shovel
  --image: rabbit-alpine
  --volume: ./amqp-conf

вообщем - мысль формируется… перенесу ка я ей в отдельную

Гибкий запуск RabbitMQ - движемся к космосу последовательно
#2

@EvilBeaver - на мысль навели

Компоненты

  • @Yakimovich - писал в рамках курса на C#
  • в рамках OScript мы все пишем понемногу на C# и Mono
  • @Bronislav у себя также пилил на C#
  • мы сейчас пишем на C++

Контексты

  • мы сделали на NativeAPI, потому как librabbitmq-c быстрей остальных и меньше всех течет по памяти
  • NativeAPI не тратить время на маршалинг типов из 1С в компоненту и обратно
  • подписка на внешнее событие на Native API работает быстрей и возможен быстрый RPC через Callback

Вопросы

  • будем ли мы использовать Rabbit в OScript ?
  • внешние компоненты для мобильных приложений - это новая фишка платформы (Дима Шерстобитов точно подключится, если ему анонсировать такое) - на чем писать ? NativeAPI есть и у Андроида, а вот у iOS по моему нет.
#3

У меня в планах компоненту писать на C++ (Native API), ограничение по платформе 8.3.10+. Это ближе к Новому Году и только планы.
С компонентой C# (не COM) есть огромные проблемы при передаче 1GB+ обменов, а так же когда обмены высокой частоты. Эксперементально пришли к тому, что Events ходят по HTTP-интерфейсу RabbitMQ, a RPC через C# компоненту по TCP.

Выглядит хорошо, но как это провернуть чисто &НаСервере, не привязываясь к сеансу пользователя\фонового задания.
Пока приходиться использовать сторонний сервис, тот же Zato ESB для пинков 1С по HTTP.

#4

Вопрос именно и стоит в том, поделиться с тобой NativeAPI компонентой и на каких условиях :wink: C# течет по памяти.

Что касается RPC - тут сложней, есть 3 разных арх.решения как выкрутиться, все палить не буду…

Но главное тут вот что:

“Шатл интеграции” позволяет запускать интеграционный адаптер к 1С рядом со службами сервера и имплементировать RPC и остальную микросервисность. И делать это быстро.

были у меня эксперименты с https://github.com/rabbitmq/rabbitmq-metronome/blob/master/src/rabbit_metronome_worker.erl, но Erlang как то жесток оказался.

#5

Вопрос именно и стоит в том, поделиться с тобой NativeAPI компонентой и на каких условиях.

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

C# течет по памяти.

Компонента может течь из-за сборщика мусора, это и так понятно.

“Шатл интеграции” позволяет запускать интеграционный адаптер к 1С рядом со службами сервера и имплементировать RPC и остальную микросервисность. И делать это быстро.

Это уже реализовано у нас как служба сервера :slight_smile:
Идеальный вариант разворачивать из Docker’a.

#6

Строго говоря, затраты на маршалинг данных между 1С и C++ есть, но не столь критичные, как в случае managed/unmanaged и COM IDispatch

#7

Думаю, сначала обкатаем внутри, потом выложим платно, но недорого. Насчет опенсорса, пока рано, имхо.

1 Симпатия