← На главную

В процессе разработки на платформе 1С:Предприятие 8.3 (особенно в версиях ветки 8.3.13 и 8.3.14) многие программисты сталкиваются с неприятной особенностью: после закрытия отладочного приложения в конфигураторе продолжает висеть активный серверный сеанс. Этот сеанс невозможно завершить стандартными средствами, он не отображается в консоли администрирования кластера в разделе «Сеансы», но при этом блокирует повторную отладку или вносит путаницу в список подключенных предметов отладки. Разберем подробно, почему это происходит и как эффективно бороться с этим явлением без перезагрузки всего сервера приложений.

Выясняем причины возникновения фантомных сеансов

Для начала проанализируем ситуацию: почему сеанс «зависает»? В версиях 8.3.13.1664 и смежных релизах механизмы взаимодействия между Конфигуратором, Сервером приложений и Сервером отладки (dbgs) претерпели изменения. Основные причины кроются в следующем:

1. Особенности протокола TCP/IP: При использовании классической отладки по TCP сеанс может остаться открытым, если сокет не был корректно закрыт со стороны клиентского приложения. Если конфигуратор «потерял» связь с процессом отладки, сервер будет продолжать ожидать ответа, считая сеанс активным.
2. Фоновые задания: Часто при возникновении ошибки в коде или принудительном прерывании отладки остаются активными потоки фоновых заданий. Сервер удерживает отладочный контекст до тех пор, пока фоновое задание не завершится или не получит команду на остановку от отладчика.
3. Нестабильность HTTP-отладки в ранних релизах: Хотя протокол HTTP призван решить проблемы с портами и брандмауэрами, в первых реализациях (как раз 8.3.13) механизмы очистки «брошенных» сеансов работали некорректно.

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

Способ 1: Манипуляции внутри Конфигуратора

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

Использование горячих клавиш. Попробуем принудительно остановить все текущие процессы отладки. Для этого в конфигураторе нажмем комбинацию Shift + F5. В некоторых случаях это посылает сигнал на сервер о завершении всех связанных потоков, включая фоновые задания, которые могли удерживать сеанс.

Повторное подключение. Рассмотрим алгоритм «перехвата» сеанса:

1. Перейдем в меню Отладка — Подключение.
2. В открывшемся окне найдем наш «зависший» сеанс в списке доступных предметов отладки.
3. Попробуем нажать кнопку Подключить. Если подключение удалось, снова нажмем Shift + F5 для корректного завершения.

Способ 2: Перезапуск Конфигуратора

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

Способ 3: Работа с процессами на сервере (dbgs)

Если сеанс продолжает висеть и мешает работе, а доступа к перезагрузке всего сервера 1С нет, мы можем воздействовать на конкретный процесс, отвечающий за отладку. Проанализируем работу службы сервера 1С. За отладку отвечает отдельный процесс или поток dbgs.exe (в случае выноса отладки на отдельный сервер).

Если в параметрах запуска службы сервера 1С используется флаг -debug, то на сервере функционирует менеджер отладки. Выясним причину зависания через диспетчер задач на сервере приложений:

1. Найдем процесс dbgs.exe (если он запущен как отдельный процесс).
2. Завершение этого процесса приведет к сбросу всех текущих отладочных сессий всех разработчиков в данной базе, но не затронет обычных пользователей.
3. После завершения процесса система автоматически запустит его снова при следующей попытке начать отладку из конфигуратора.

Способ 4: Очистка через «Соединения» в консоли кластера

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

Откроем консоль администрирования кластеров 1С, перейдем в дерево нашего кластера и выберем пункт Соединения (Connections). Очень часто «фантомный» сеанс отладки отображается именно здесь как низкоуровневое TCP-соединение. Проанализируем колонку «Приложение» — там будет указано «Отладчик» или «Debugger». Удаление этого соединения принудительно разорвет связь сервера с зависшим предметом отладки.

Способ 5: Переход на HTTP-отладку

Для предотвращения подобных ситуаций в будущем, особенно на релизах 8.3.13 и выше, рекомендуется сменить протокол отладки с TCP на HTTP. Рассмотрим, почему это эффективнее:

• HTTP-отладка не требует постоянного открытого TCP-соединения, которое может «зависнуть» на сетевом уровне.
• Она стабильнее работает через брандмауэры и NAT.
• Механизмы завершения сеансов по таймауту в HTTP-протоколе реализованы более жестко.

Для включения HTTP-отладки необходимо выполнить следующие шаги:

1. В настройках службы сервера 1С (через реестр или файл конфигурации) добавить параметр -http.
2. Пример строки запуска: "C:\Program Files\1cv8\8.3.13.1664\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug -http.
3. В конфигураторе зайти в Сервис — Параметры — Отладка и установить переключатель в положение Использовать протокол HTTP.

Резюме

Мы разобрали ситуацию с зависанием отладочных сеансов, которая является следствием архитектурных особенностей платформы 1С версии 8.3.13. Подведем итог: если вы столкнулись с такой «фичей», первым делом используйте Shift + F5 и проверку окна «Подключения». Если это не помогает, проверьте раздел Соединения в консоли кластера. В долгосрочной перспективе лучшим решением станет переход на протокол HTTP, который минимизирует вероятность появления подобных фантомных сеансов.