Почему зависают фоновые задания при вызове WEB-сервисов в 1С и как это исправить?

В процессе интеграции 1С с внешними системами через WEB-сервисы разработчики часто сталкиваются с ситуацией, когда фоновые задания обмена периодически «вешаются». Сеансы перестают завершаться, обмен данными останавливается, а при попытке открыть форму внешнего обработчика в тонком клиенте пользовательский интерфейс полностью замирает. Временным «лечением» становится рестарт службы сервера 1С:Предприятие, однако спустя несколько дней проблема повторяется вновь.

Проанализируем основные причины возникновения этой неисправности, разберем записи технологического журнала и рассмотрим практические способы полного устранения зависаний.

Основные причины зависания процессов и обрывов соединений

Выясним, какие технические факторы вызывают подобное поведение системы:

1. Бесконечное ожидание ответа от WEB-сервиса (отсутствие таймаутов): По умолчанию при вызове конструктора WSОпределения и создании WSПрокси платформа 1С выполняет синхронные сетевые запросы. Если внешний сервис зависает, испытывает сетевые проблемы или не закрывает соединение, рабочий процесс 1С (rphost) остается в бесконечном ожидании ответа сокета.
2. Использование PostgreSQL без специализированных патчей от 1С: При работе с неадаптированными сборками СУБД в технологическом журнале появляется ошибка ERROR: syntax error at or near "application" LINE 1: lock table pg_class in application share mode. Стандартный PostgreSQL не поддерживает режим блокировок APPLICATION SHARE, что приводит к сбоям транзакций и блокировкам таблиц.
3. Занятость сетевых портов и зависание сокетов в ОС Linux: При частых сетевых обменах и сбоях потоков сокеты межпроцессного взаимодействия могут оставаться в состоянии TIME_WAIT, вызывая ошибки вида NetDataExchangeException: Address already in use.
4. Утечки ресурсов при регулярном подключении внешних обработок: Динамический запуск ВнешниеОбработки.Подключить() на сервере без явного освобождения ресурсов приводит к накопительному росту сеансовых данных в памяти rphost.

Способ 1. Установка таймаутов для объектов WSОпределения и WSПрокси

Разберем самый оперативный способ предотвращения зависания потоков. При создании сетевых объектов необходимо явно задавать ограничение времени ожидания ответа в секундах.

Рассмотрим пример кода, в котором выполняется подключение к WEB-сервису с установкой таймаута:

// Инициализация WSDL-определений с указанием таймаута (например, 9 секунд)
Определения = Новый WSОпределения(
    "http://example.com/ws/service.1cws?wsdl", 
    СокрЛП(Настройки.Логин), 
    СокрЛП(Настройки.Пароль), 
    , 
    9
);

// Создание WSПрокси с явной передачей таймаута в шестом параметре конструктора
Прокси = Новый WSПрокси(
    Определения, 
    "ControlOfExternalModules", 
    "WSImportDate", 
    "WSImportDateSoap", 
    , 
    9
);

Прокси.Пользователь = СокрЛП(Настройки.Логин);
Прокси.Пароль = СокрЛП(Настройки.Пароль);

// Также допускается отдельное присвоение свойства (если прокси создан без конструктора WSDL):
// Прокси.Таймаут = 9;

Результат = Прокси.ImportDate(СтруктураДанныхОтправки);

Важное замечание: Передача таймаута в шестой параметр конструктора WSПрокси или установка свойства Прокси.Таймаут гарантирует, что при сетевом сбое фоновое задание не повиснет бессрочно, а завершится по ошибке через указанное количество секунд, освободив рабочий процесс rphost.

Способ 2. Корректная очистка временного хранилища при работе с внешними обработками

Посмотрим на пример процедурной работы с динамически подключаемыми модулями. Чтобы избежать утечки оперативной памяти и зависания сеансовых данных, после завершения работы с обработкой необходимо явно вызывать метод УдалитьИзВременногоХранилища().

Процедура ОповеститьОбработчик(ВнешнийОбработчик, Событие, ОбъектСобытия, ДанныеДляОбработки, ВнешнееСобытие) Экспорт
    Менеджер = ВнешниеОбработки;
    
    Попытка
        АдресВоВременномХранилище = ПоместитьВоВременноеХранилище(ВнешнийОбработчик.ХранилищеОбработки.Получить());
        ИмяОбработки = Менеджер.Подключить(АдресВоВременномХранилище, , Ложь);
    Исключение
        ЗаписьЖурналаРегистрации("Создание внешнего модуля: ОШИБКА! '" + ОписаниеОшибки() + "'", УровеньЖурналаРегистрации.Предупреждение);
        ИмяОбработки = Неопределено;
    КонецПопытки;
    
    Если НЕ ИмяОбработки = Неопределено Тогда
        ОбработкаОбъект = Менеджер.Создать(ИмяОбработки);
        
        // Передача настроек в обработку
        Настройки = Новый Структура;
        Настройки.Вставить("СсылкаНаМодуль", ВнешнийОбработчик.Ссылка);
        ОбработкаОбъект.Настройки = Настройки;
        
        Если НЕ ВнешнееСобытие Тогда
            ОбработкаОбъект.ОбработатьВнутреннееСобытие(СокрЛП(Событие), ОбъектСобытия);
        Иначе
            ОбработкаОбъект.ОбработатьВнешнееСобытие(ДанныеДляОбработки);
        КонецЕсли;
    КонецЕсли;
    
    // Обязательная очистка временного хранилища для предотвращения утечек памяти
    УдалитьИзВременногоХранилища(АдресВоВременномХранилище);
КонецПроцедуры

Способ 3. Проверка сборки PostgreSQL и параметров платформы 1С

Проанализируем ошибки СУБД, зафиксированные в технологическом журнале. Наличие записи ERROR: syntax error at or near "application" LINE 1: lock table pg_class in application share mode свидетельствует о том, что используемая база данных PostgreSQL не содержит специальных патчей от фирмы «1С».

Для исправления проблемы выполним следующие действия:

1. Замена дистрибутива PostgreSQL: Установим дистрибутив PostgreSQL, предназначенный специально для работы с платформой 1С:Предприятие (например, официальные сборки от Postgres Professional или фирменные дистрибутивы с Портала 1С).
2. Обновление платформы 1С:Предприятие: В устаревших релизах платформы (в частности, линейки 8.3.6 – 8.3.8) наблюдаются платформенные утечки сетевых сокетов при работе под управлением Linux (CentOS). Обновление платформы на актуальные релизы (8.3.10 и новее) полностью ликвидирует данную проблему.

Рекомендации по повышению отказоустойчивости

Чтобы окончательно стабилизировать работу сервисных обменов, учтем следующие архитектурные рекомендации:

1. Использование метаданных «WS-ссылки»: Вместо динамической загрузки WSDL по сети через WSОпределения рекомендуется импортировать WSDL-схему напрямую в конфигурацию в объект «WS-ссылки». Это исключит лишние HTTP-запросы на получение структуры сервиса.
2. Отказ от частых вызовов ВнешниеОбработки.Подключить(): Логику обработки входящих и исходящих данных лучше выносить в общие модули конфигурации или Внедряемые Расширения (.cfe).
3. Настройка автоматического перезапуска rphost: В консоли администрирования серверов 1С следует задать допустимый объем виртуальной памяти для рабочих процессов rphost и интервал его превышения, чтобы кластер перезапускал процессы со сниженной производительностью без остановки всей службы.