-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Падение процессов сервера 1с при работе с компонентой #79
Comments
Наткнулись на ровно эту же проблему. До логов и журнала еще не дошел, но поведение тоже. А вот следующий раз когда запускается фоновое и выполняет этот же код, на строке с Connect убивает напрочь фоновое задание. у меня "КлиентКомпоненты = Неопределено", небыло (из примеров скопировал, на правило не обратил внимание)... был уверен что изза этого каждый второй валисться... но нет. добавил, не помогло. Параметры для Connect ранее были в структуре в 1С, вынес в отдельные переменные, и тоже обнуляю теперь после использования. Тоже не помогло. Самое обидное что валит весь сеанс фонового задания которое это дело запускает, и поэтому и то что connect обернут в Попытка/Исключение не чего не дает. из лога у sliderv заметил что у нас у обоих это веселье в расширение, может это как то влияет? `
КонецФункции |
Столкнулись с подобной ситуацией на линуксе. Каждая вторая попытка работать с компонентой заканчивается ошибкой "Аварийно завершился рабочий процесс фонового задания". Коллеги, удалось справиться с проблемой? |
мы пока перешли на винду. но тут тоже эта проблема проявлялась (возможно по разным причинам). тестировать эту схему на постгресе буду уже после того как все остальное в проекте сделаем на винде и будем пытаться запустить рабочий сервис. |
Я тоже борюсь с падениями rphost'ов и уже несколько раз наткнулся, что последней строкой в техжурнале перед падением rphost было: Переписал код на использование компоненты в изолированном режиме (реализовано в 1С 8.3.21) - все равно получил падение rphost на строчке: Компонента = Новый("AddIn.BITERP.PinkRabbitMQ"); |
Добрый день! При отправке сообщения через фоновое задание так же рубит фоновое на второй раз. Удалось ли решить проблему на компонентах для linux? |
У меня также было, плюс файлы были слишком большие для передачи, клиент при длительной обработке сообщения отваливался, при этом можно было подтвердить получение сообщения, и компонента писала, что все хорошо, при последующем получении сообщений отвечало, что они закончились, из-за этого происходило зацикливание обработки сообщения, так как его не успевали подтвердить. Пришлось отказаться от компоненты на работу через COM, теперь работает как часы |
Всем привет! Так же имеется проблема с методом Connect. Только в отличии от других жалоб, происходит ребут всего сервера. Ошибка происходит только при защищенном подключении. В логах винды удалось определить последовательность ошибок: затем: 1С серверная x64, версия 8.3.20.1996 Код 1С: |
Аналогичная проблема на линкус сервере с последней версией. На версии 1.9 таких проблем не наблюдаем. |
Приветствую!
Существует проблема, которую не знаю как решить, не знаю баг это или сервера, или компоненты.
Сервер 1с на linux (x64 CentOS Linux release 7.9.2009). Сервер 1с - 8.3.20.1789 (пробовал также на 8.3.20.1674)
Релиз компоненты - последний доступный (пробовал и на других более младших релизов).
Падение происходит при вызове метода Connect на 2-й или 3-й раз в рамках одного сеанса. При этом после каждого вызова всегда осуществляется очистка клиента (Клиент = Неопределено). Первый вызов всего кода всегда проходит успешно.
Клиент.Connect(Параметры.АдресСервера, Параметры.Порт, Параметры.ИмяПользователя, Параметры.Пароль, Параметры.Хост, , , 600);
Код модуля в общем то стандартный:
` Клиент = ВернутьКлиентRMQ();
В логах компоненты пишется при падении :
[D 2022-04-12 16:37:31 1649763451 140232744187648]init
[D 2022-04-12 16:37:31 1649763451 140232744187648]init end
[D 2022-04-12 16:37:32 1649763452 140232744187648]1C call proc start 1
Вот лог компоненты при успешном вызове кода:
[D 2022-04-12 16:37:04 1649763424 140431454095104]init
[D 2022-04-12 16:37:04 1649763424 140431454095104]init end
[D 2022-04-12 16:37:05 1649763425 140431454095104]1C call proc start 1
[D 2022-04-12 16:37:05 1649763425 140431454095104]1C call proc end 1
[D 2022-04-12 16:37:06 1649763426 140431454095104]1C call func start 2
[D 2022-04-12 16:37:06 1649763426 140431454095104]1C call func end 2
[D 2022-04-12 16:37:06 1649763426 140431454095104]1C call func start 4
[D 2022-04-12 16:37:06 1649763426 140431454095104]1C call func end 4
[D 2022-04-12 16:37:06 1649763426 140431454095104]1C call func start 5
[D 2022-04-12 16:37:11 1649763431 140431454095104]1C call func end 5
[D 2022-04-12 16:37:11 1649763431 140431454095104]1C call proc start 6
[D 2022-04-12 16:37:11 1649763431 140431454095104]1C call proc end 6
[D 2022-04-12 16:37:12 1649763432 140431454095104]done start
[D 2022-04-12 16:37:12 1649763432 140431454095104]done
[D 2022-04-12 16:37:12 1649763432 140431454095104]done end
[D 2022-04-12 16:37:12 1649763432 140431454095104]destruct
В технологическом журнале 1с:
The text was updated successfully, but these errors were encountered: