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

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

Consumer was cancelled: amq.ctag-r20rkTIrf3XHVNBI1kqwLg

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

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

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

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

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

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

Клиент.Connect( …

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

Клиент.BasicConsume(…

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

Клиент.BasicConsumeMessage(…

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

Клиент.BasicCancel(…

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

Consumer was cancelled: amq.ctag-r20rkTIrf3XHVNBI1kqwLg

?

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

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

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

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

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

1 Симпатия

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

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

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

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

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

Consumer was cancelled

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

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

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 фактически

1 Симпатия

Стало легче ?

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

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