Так хорошо, т.е. это не бага (что то падает не

работает как описано в доке и т.п.), а вопрос "Как сделать так, чтобы через розового кролика постоянно слушать очередь не разрывая соединение, и как только только придет сообщение обрабабтывать его в 1С" так?

Насколько я понял там ещё параллельно проблема в том, что компонента на таки иногда падает

Именно

Ну выглядит это примерно как не читает сообщения при вызове метода начать чтение

Ответ на вопрос "как постоянно слушать" вот здесь https://github.com/BITERP/PinkRabbitMQ#%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B-%D1%81-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%BE%D0%B9-%D0%B8%D0%B7-1%D1%81 Т.е. запускаем фоновое задание, выбираем достатчоно большой Таймаут (скажем 10 мин), и код 1С "висит" в начале цикла пока не придет новое сообщение или не пройдет 10 мин, таким образом достигается мгновенная реакция из 1С на новое сообщение (и соединение будет висеть). Или я не так понял вопрос

Что качается ошибок с падением компоненты: В данный момент мы знаем, что такая ошибка бывает если 2х параллельных фоновых заданиях работает компонента (скажем читает данные из очереди). Это связано с особенностью платформы, что она создает общий КЭШ для одноименных компонент даже для разных экземпляров из разных заданий и прибивает его после того как первое задание закончится. Эта проблема побеждается в 21 платформе когда можно внешние компоненты запускать в отдельных процессах

Хм)

Родилась смешная идея, завтра попробую скомпилировать компоненту под разным именем и запустить в 3 потока (кеш же станет разным?))))