BasicConsumeMessage падает в исключение Consumer was cancelled

1c

#1

У нас периодически появляется ошибка при выполнении функции BasicConsumeMessage:

Consumer was cancelled: amq.ctag-r20rkTIrf3XHVNBI1kqwLg

Не могу понять из-за чего возникает данная ошибка и как от неё избавиться.
Подскажите что это и как с этим можно побороться?


#2

А как вы умудряетесь ее выполнить - :wink: эту функцию.

Она же в библиотеке. А эксепшен у вас выглядит как исключение из Клиента RPC.


#3

Как-то не легче стало))
Может краткое описание поможет.
Кратко код в 1С выглядит вот так:
Создаём экземпляр длл-ки

Клиент = Новый(“AddIn.V8RMQClient.V8RMQClient”);

Конектимся к кролику

Клиент.Connect( …

Начинаем чтение

Клиент.BasicConsume(…

Получаем в цикле сообщения

Клиент.BasicConsumeMessage(…

Дальше обрабатываем их и заканчиваем чтение

Клиент.BasicCancel(…

При каких сценариях BasicConsumeMessage возвращает:

Consumer was cancelled: amq.ctag-r20rkTIrf3XHVNBI1kqwLg

?


#4

Зачем вы работаете с DLL ? Для проверки работы есть Демо_Консоль

это во первых.

Во вторых я такие эксепшены видел когда неверно установлены тэги клиента - наблюдалось у C# клиентов.

Почему вы пишите низкоуровневые методы работы с компонентой ? У вас нет подсистемы ?


#5

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


#6

Да понятно чем вызвано - причин комплекс. Оно воспроизводится на всех клиентах.

Сочетания трех параметров

  • паралельное чтение из одной очереди
  • длинная обработка сообщения и соответственно отсутствие обратной связи ACK или NACK - причем отсутвие в 2 раза большей чем параметр ЧастотаПульса

Лечится просто - выставляется частота пульса у Соединения.

Собственно ошибка то и звучит почти читаемо

Consumer was cancelled

То есть клиента пристрелили, так как он не прислал ни да, ни нет за отведенное время.


#7

Официальная цитата из документации

Consumers in your code can fail to acknowledge messages or take longer than usual

Что в вольном переводе - возвращать ответ нужно как можно быстрей, до того момента пока сервер не посчитал соединение “мертвым”

Нововедение которое это дело закрывает (на стороне клиента) - Релиз 1.7 - ПульсСоединениеяССвервером

Для начала лучше смотреть сюда - https://www.rabbitmq.com/troubleshooting-networking.html

Пристрел клиента со стороны клиента - это однозначно сетевые проблемы.

P.S. И вот на что ты меня навел сейчас. Сделать дефолтный ConsumerTag на уровне 1С кода - так будет удобней для расследования. Сейчас в сигнатуре метода метку подписчика можно выставить, но все забывают

amq.ctag-r20rkTIrf3XHVNBI1kqwLg

Это как раз автоматически генерированная метка подписчика

amq - это пространство имен зарерервированное за RabbitMQ
ctag - сокращение от “метки подписчика”
r20rkTIrf3XHVNBI1kqwLg - GUID фактически


#8

Стало легче ?


#9

Помогло ? Или пока не занимались ?


#10

Спасибо за пояснения.
Не смог воспроизвести, поэтому пока отложили эту проблему.
Воспроизводить пробовал с помощью отмены отправки подтверждения и задержки между получением. Всё четно. Времени на не критическую ошибку нет, оставили до худших времён.