Накодил обмен 1С через вашу компоненту с самодельным сторонним приложением.
С обоих сторон предусмотрены постоянно работающие фоновые получение и отправка сообщений.
Тестирую поведение системы при различных сбоях. Наблюдаю такое поведение компоненты (последней версии):
1) Обрыв сети.
При имитации обрыва сети публикация реагирует адекватно, исключением "Frame could not be sent", что дает возможность публикацию перезапустить. А вот чтение на обрыв не реагирует, продолжает спокойно без ошибок выполняться в цикле "BasicConsumeMessage", при том что реально соединение уже оборвалось, и при его физическом восстановлении чтение не восстанавливается. Неудобно, но с этим можно бороться периодическим перезапуском фонового задания с чтением. Компонента не зависает и фоновое задание можно нормально завершить.
2) Падение/перезапуск сервера RabbitMQ
А вот тут все предельно печально. Публикация сразу, при первой же попытке что-то отправить, зависает вместе с фоновым заданием, исключений не выдает. Чтение продолжает крутить "BasicConsumeMessage", но фоновое задание по факту тоже зависшее. Оба фоновых задания занимают на 100% по одному ядру сервера, штатно не завершаются - только рестарт сервера 1С.
Для контраста - стороннее приложение на C#, с использованием родной библиотеки "RabbitMQ.Client" и установленным для "ConnectionFactory" свойством "AutomaticRecoveryEnabled = true" все сбои переживает без проблем, соединение автоматически восстанавливает...
Хотелось бы любого из двух вариантов: или исключений при любых сбоях соединения с сервером "RabbitMQ или автоматического восстановления соединения.
Ну, или как совсем компромисс, такой-себе, хотя бы чтобы зависшая компонента ядро проца на 100% не занимала.
Накодил обмен 1С через вашу компоненту с самодельным сторонним приложением. С обоих сторон предусмотрены постоянно работающие фоновые получение и отправка сообщений. Тестирую поведение системы при различных сбоях. Наблюдаю такое поведение компоненты (последней версии): 1) Обрыв сети. При имитации обрыва сети публикация реагирует адекватно, исключением "Frame could not be sent", что дает возможность публикацию перезапустить. А вот чтение на обрыв не реагирует, продолжает спокойно без ошибок выполняться в цикле "BasicConsumeMessage", при том что реально соединение уже оборвалось, и при его физическом восстановлении чтение не восстанавливается. Неудобно, но с этим можно бороться периодическим перезапуском фонового задания с чтением. Компонента не зависает и фоновое задание можно нормально завершить. 2) Падение/перезапуск сервера RabbitMQ А вот тут все предельно печально. Публикация сразу, при первой же попытке что-то отправить, зависает вместе с фоновым заданием, исключений не выдает. Чтение продолжает крутить "BasicConsumeMessage", но фоновое задание по факту тоже зависшее. Оба фоновых задания занимают на 100% по одному ядру сервера, штатно не завершаются - только рестарт сервера 1С.
Для контраста - стороннее приложение на C#, с использованием родной библиотеки "RabbitMQ.Client" и установленным для "ConnectionFactory" свойством "AutomaticRecoveryEnabled = true" все сбои переживает без проблем, соединение автоматически восстанавливает...
Хотелось бы любого из двух вариантов: или исключений при любых сбоях соединения с сервером "RabbitMQ или автоматического восстановления соединения. Ну, или как совсем компромисс, такой-себе, хотя бы чтобы зависшая компонента ядро проца на 100% не занимала.