Пожелания к редакции Yellow-rabitmq 1.X

yrmq

#1

сижу планирую релиз, есть у кого особые пожелания на расширение API компоненты ?

у нас сейчас в работе небольшие задачи

v8rmq-native - компонента

Мелкие улучшения

по компоненте

  • русскоязыные альясы методов
  • поддержка всех штатных свойств (properties)
  • поддержка таблицы заголовков (headers)
  • поддержка автоматического ZIP сообщений через content-encoding и content-type

про заголовки - можно получить ключ маршрутизации

ИмяПодписчика = Компонента.ПодписатьсяНаОчередьСообщений(<параметры_очереди>);
Сообщение = Неопределено;
КлючМаршрутизации = Неопределено;
Таймаут = -1;
Компонента.ПолучитьРасширенноеСообщенияДляПодписчика (
      ИмяПодписчика, Сообщение, КлючМаршрутизации,  Таймаут);
Сообщить(Сообщение, КлючМаршрутизации);

про свойства - их не так много

content_type
content_encoding
priority
correlation_id
reply_to
expiration
message_id
timestamp
type
user_id
app_id
cluster_id

есть кстати желание свойствам придумать “русские альясы” - но это как бы наверное перебор.

про ZIP - подсмотрено у питонистов

это из RFC для передачи сообщения, когда ZIP осуществляется сразу на клиенте - и это штатная функциональность RabbitMQ

Позволяет сократить место на диске под очереди/точки обмена которые очень не хочется потерять и память под очереди которым нужна высокая пропускная способность в среднем 5 раз

EPIC (глобальные)

  • Android сборка и iPhone сборка - там остался только вопрос сборки и правильного манифеста
  • отдельный объект для Apache Kafka - кстати там по умолчанию все сообщения сразу в ZIP

v8rmq-subsystem - подсистема

EPIC (глобальные)

  • чуть больше покрытия BDD
  • поддержка работы с EnterpriseData - http://v8.1c.ru/edi/edi_app/enterprisedata/ в части “квитирования”
  • немного рефакторинга кода до оптимальности - SonarQube нам в помощь (чем больше правил появляется - тем больше некачественного кода выявляется) - вроде умные-умные, а при разработке всего не упомнишь

Про EData - для завтравки (вы знали что имена очередей могут быть на русском :wink:

пойдет как часть зависящая от БСП - все таки, там есть уже готовая поддержка

В комментариях пишите - чего бы вы хотели ещё

особенно интересует мнение @Bronislav @sergey.novikov @Gleb_Stalnoy и @a.sosnoviy


#2

Заголовки и свойства это отлично, тк пришлось их запилить внутри сообщений.
Имена очередей на русском, почему бы и нет, но на скриншоте почему-то exchange :slight_smile:
Из улучшений, хотелось бы: https://www.rabbitmq.com/heartbeats.html , так как сталкивались с проблемой зависших наглухо tcp соединений, из-за чего даже фоновое задание пристрелить не получалось, в котором это соединение зависло.


#3

Как-то неправильно, когда у нас входящие и исходящие параметры в параметрах передаются. Здесь явно просится фукция:

Данные = Компонента.ПолучитьРасширенноеСообщенияДляПодписчика (ИмяПодписчика, Таймаут);

Сообщение = Данные.Сообщение;
КлючМаршрутизации = Данные.КлючМаршрутизации;


#4

Это для производительности на самом деле. Тут надо погружаться в С++, но если коротко то 1С со сложными объектами между NativeAPI и платформой 1С будут определенные грабли в части так называемого маршалинга (то есть переброски) и выделения для них памяти уже на стороне платформы. Так как на самом деле из компоненты возвращается копия строки (числа, т.д.), где память выделяется уже менеджером памяти 1С.

В приведенным пример Данные - это уже сложный объект (типа Структура). А объект требует указатель.

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

Причина этого известна - работа менеджера памяти с типами (сложными) VTYPE_BLOB, VTYPE_STR_BLOB, VTYPE_VECTOR и VTYPE_ARRAY была раньше не стабильна.

Учитывая что тема про пожелания - мы можем расширить API компоненты до такого, но гарантировать работу подобных типов можем только с 8.3.10 когда на партнерке официально были закрыты баги по работе со сложными типами.

P.S. Записал себе в “бэклог”


#5

Проверил. Такое возможно и доступно. Сделаем быстро.

#define AMQP_FRAME_HEARTBEAT 8 /**< Constant: FRAME-HEARTBEAT */


#6

Я лично с начало года жду функционала для мобильной платформы под android, так как на проекте есть ограничения и только с rabbit их можно обойти.


#7

Тут еще момент с ограниченностью интерфейса NativeAPI. Он не позволяет передавать между 1С и компонентой сложные типы (см. сообщение от @lustin) на настоящий момент. Поэтому низкоуровневый интерфейс возможен только на уровне процедурного программирования. Никаких объектов.

В какой-то мере здесь спасает 1С-ная подсистема. В ней можно завернуть все сложности NativeApi и отдавать уже “объектные” данные.

Кстати, вообще не рекомендуется сильно завязывать свой код на методы компоненты, а вместо этого использовать предлагаемые обертки из подсистемы. Во-первых, там более предлагается удобная обработка исключений (опять же, из-за ограниченности NativeApi). Во-вторых, API компоненты активно развивается и может меняться в будущем. На стороне 1С мы, безусловно, обеспечим бесшовный переход между версиями, а вот поддерживать обратную совместимость на уровне методов DLL будет чуть сложнее.


#8

Только что вспомнили, наступив на это второй раз, что при создании очередей не плохо бы иметь возможность из компоненты для очереди определять аргументы:
Message TTL | Dead letter exchange | Dead letter routing key


#9

Добавляю прототипы протоколов

  • nats
  • deepstream
  • kafka

их их обертка


#10

@Bronislav - смотри, по heartbeats. предварительно это будет метод Tune/НастроитьСоединение с тремя параметрами

  • максимальное количество каналов (по умолчанию 0 - без ограничения)
  • размер стандартного фрейма (по умолчанию 131072, то бишь 128 килобайт)
  • задержка в секундах для heartbeats - по умолчанию 0, без heartbeat

В твоем случае нужно будет вызвать метод

Компонента.Tune(,,8);
Компонента.НастроитьСоединение(,,8);

будет установлена задержка в 8 секунд - если сервер подтвердит что он такое поддерживает. RMQ старше 3 редакции такое поддерживают

Причем - очень важный момент. Оно может вернуть “Фиг” - если вдруг будет использоваться старый RMQ.
Согласно протокола - сервер и клиент должны вернуть друг-другу ОК если тюнинг удался

https://www.rabbitmq.com/amqp-0-9-1-reference.html#connection.tune

P.S. Вмержено в ближайший develop


Зависшие соединения на сервере rabbit
#11

Поддерживаю. Версия для мобильной платформы под Andrioid была бы кстати.


#12

Добавил в develop - отлаживаю API. Я думаю к концу следующей недели будет релиз со всеми наработками. BDD еще покрытие проверим и в бой.

P.S. Я тут потихоньку описываю протокол в документе - а то не все знают эти магические понятия


#13

Алексей, добрый день.
Вышел ли уже релиз компоненты с поддержкой kafka? Если нет, то можете указать примерные сроки его выпуска?


#14

Пока вот такое делается.

вы первый который спросил про Kafka после Инфостарта.