При работе с веб-сервисами 1С системные администраторы и разработчики часто сталкиваются с ситуацией, когда в консоли администрирования кластера «висит» сеанс, который невозможно завершить стандартными средствами. При попытке удаления такого сеанса он исчезает на мгновение, но тут же появляется снова под тем же или новым номером. Ситуация осложняется тем, что на сервере может работать множество баз, и полная перезагрузка службы 1C:Enterprise 8 Server Agent или сервера СУБД недопустима из-за активных пользователей.
В этой статье мы разберем механизмы возникновения таких «бессмертных» сеансов и рассмотрим пошаговые методы их гарантированного устранения без остановки всей инфраструктуры.
Прежде чем переходить к радикальным мерам, выясним причину такого поведения системы. Разберем ситуацию: когда клиент (внешняя система, мобильное приложение или другая база 1С) обращается к веб-сервису через HTTP/HTTPS, веб-сервер (IIS или Apache) создает соединение. Если в настройках публикации или на стороне клиента не настроены жесткие тайм-ауты, HTTP-соединение может оставаться активным («Keep-Alive»).
Когда мы удаляем сеанс в консоли кластера 1С, мы убиваем лишь логическую сущность внутри кластера. Однако физическое сетевое соединение со стороны веб-сервера к рабочему процессу 1С остается открытым. Веб-сервер, видя, что сеанс разорван, но запрос клиента еще не завершен, инициирует повторное создание сеанса. Проанализируем способы, которые помогут разорвать эту цепочку.
Если сеанс «залип» настолько плотно, что не реагирует на команды консоли, нам необходимо воздействовать на рабочий процесс rphost, который его обслуживает. Рассмотрим, как это сделать точечно:
1562).rphost.exe с нужным PID и завершим его.Важно: При завершении rphost все остальные пользователи, чьи сеансы находились в этом же процессе, будут аварийно отключены, но их сеансы перейдут в другие рабочие процессы (если настроено резервирование) или им придется переподключиться. Это гораздо менее болезненно, чем перезапуск всей службы ragent.
Часто проблема кроется не в самом 1С, а в том, что веб-сервер IIS удерживает запрос. Если веб-сервис опубликован на IIS, мы можем воздействовать на его рабочие процессы w3wp.exe. Разберем ситуацию, когда несколько баз используют один пул приложений.
Если мы просто остановим пул приложений в диспетчере IIS, «лягут» все сайты, привязанные к нему. Чтобы действовать избирательно, проанализируем текущие запросы:
w3wp.exe и соответствующие им пулы приложений.Если же «дятлы» (как выразились в обсуждении) запихнули все публикации в один пул, воспользуемся утилитой appcmd. Откроем командную строку от имени администратора и введем:
%systemroot%\system32\inetsrv\appcmd list requests
Эта команда покажет все активные HTTP-запросы. Найдя зависший запрос к конкретной базе, мы можем определить ID процесса и завершить именно его через taskkill.
Чтобы сеансы не «зависали» в будущем, необходимо правильно настроить файл публикации default.vrd. В этом файле можно управлять пулом соединений 1С. Рассмотрим параметры внутри тега point:
<point ...>
<pool size="10" timeout="60" />
</point>
Где:
size — ограничивает максимальное количество одновременно удерживаемых соединений.timeout — определяет время (в секундах), через которое неиспользуемое соединение будет принудительно закрыто.Установка параметра poolTimeout в значение, например, 30 или 60 секунд, заставляет систему очищать «брошенные» или некорректно завершенные сеансы автоматически, не допуская их бесконечного накопления.
Иногда графическая консоль (MMC) не может корректно отобразить или прервать соединение. В таких случаях на помощь приходит утилита командной строки rac. Она позволяет работать напрямую с сервером администрирования ras.
С помощью rac можно не только удалить сеанс (session), но и принудительно разорвать соединение (connection). В терминологии 1С это разные сущности. Удаление именно соединения зачастую оказывается более эффективным, так как оно уничтожает низкоуровневую связь между рабочим процессом и клиентским приложением.
Если нужно мгновенно остановить работу конкретной публикации, не затрагивая настройки IIS, можно прибегнуть к «хитрости»: временно переименовать физический каталог, в котором лежит файл default.vrd этой публикации. IIS мгновенно потеряет доступ к конфигурации сайта и выдаст ошибку клиенту, разорвав связь. После этого сеанс в консоли 1С можно будет спокойно удалить, и он не восстановится.
Также проанализируем возможность блокировки на уровне сетевого экрана (Firewall). Если мы видим в консоли 1С IP-адрес клиента, который постоянно шлет запросы и восстанавливает сеанс, мы можем временно заблокировать этот IP в Windows Firewall. Как только сетевой поток иссякнет, сеанс в 1С станет «смертным».
Чтобы выяснить, почему сеанс вообще зависает (возможно, там происходит бесконечный цикл в коде или ожидание на блокировке СУБД), рекомендуем настроить Технологический журнал. Минимальный конфиг для анализа веб-сервисов должен собирать события EXCP (исключения) и CALL (вызовы методов):
<log location="C:\Logs\1C" history="24">
<event>
<eq property="Name" value="CALL"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
</log>
Проанализировав логи, мы сможем увидеть, на каком именно методе Web-сервиса прерывается исполнение, и устранить причину на уровне программного кода 1С, а не бороться с последствиями в консоли администрирования.