Почему в предметах отладки 1С остаются фантомные серверные сеансы и как их убрать

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

Проанализируем природу возникновения проблемы

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

Однако на версиях платформы 8.3.18, 8.3.20 и выше часто наблюдается рассинхронизация. Клиентский сеанс закрывается, и запись о нем пропадает, но серверный предмет отладки продолжает отображаться в конфигураторе как активный. Выясним причину: это происходит из-за того, что конфигуратор (как клиент сервиса отладки) не получает вовремя сигнал о «разрегистрации» серверного контекста или же механизм обновления списка предметов отладки внутри конфигуратора «зависает».

Разберем по шагам способ ручного удаления фантомных сеансов

Если вы обнаружили, что в списке предметов отладки висит лишний серверный сеанс, который «ничего не делает» и отсутствует в консоли кластера 1С, выполним следующие действия для его принудительной очистки:

1. Откроем окно «Предметы отладки» в конфигураторе (меню Отладка — Подключиться...).
2. Проверим список «Подключенные предметы отладки». Если там находится серверный сеанс, который должен был завершиться, выделим его.
3. Посмотрим на кнопку «Обновить» в верхней части окна. Зачастую она может быть недоступна (серая), пока фокус находится на уже подключенном предмете.
4. Попробуем «перекинуть» зависший сеанс. Если он находится в нижней части (Доступные предметы отладки), выделим его. Если он уже в верхнем списке (Подключенные), нажмем «Отключить».
5. Важный момент: как только состояние предмета отладки меняется или список переключается, кнопка «Обновить» становится активной. Нажмем её.
6. После принудительного обновления конфигуратор повторно опрашивает сервис отладки (dbgs или менеджер кластера) и, не найдя подтверждения существования сеанса, удаляет фантомную запись из списка.

Выясним причины десинхронизации: HTTP-отладка и сервис dbgs

Проанализируем техническую сторону вопроса. Современные версии платформы 1С по умолчанию используют HTTP-протокол для отладки. В этой схеме за регистрацию предметов отладки отвечает специальный сервис — Debug Server (dbgs).

Рассмотрим основные факторы, приводящие к появлению фантомов:

• Кэширование на стороне отладочного сервера: Сервис dbgs хранит таблицу активных предметов. При аномальном завершении процесса или сетевых задержках команда на удаление предмета может не дойти до сервера.
• Использование расширений: В конфигурациях уровня ERP 2.5 активно используются расширения. При динамическом обновлении или работе с кодом расширений платформа может создавать дополнительные серверные контексты, которые некорректно вычищаются отладчиком.
• Таймауты спящих сеансов: На сервере 1С сеанс может не завершаться мгновенно, а переходить в состояние «спящего». Пока сеанс окончательно не удален из таблицы сеансов кластера, он может продолжать числиться в предметах отладки.

Настройка стабильной работы отладки

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

1. Настройка параметров запуска. Попробуем явно указать адрес сервера отладки в настройках конфигуратора. Это помогает избежать ситуации, когда конфигуратор «теряет» связь с менеджером отладки. Пройдем по пути: Сервис -> Параметры -> Запуск 1С:Предприятия -> Дополнительные.

2. Очистка локального кэша. Иногда информация о предметах отладки может кэшироваться локально в профиле пользователя. В случае массового появления фантомов, стоит рассмотреть очистку папок:

%AppData%\1C\1Cv8\
%LocalAppData%\1C\1Cv8\

3. Проверка сетевых экранов. Если между сервером 1С и компьютером разработчика есть брандмауэр, он может разрывать длительные HTTP-соединения, по которым передаются сигналы отладки. Убедимся, что порты в диапазоне 1560–1591 открыты и не фильтруются.

Проанализируем ситуацию с платформой 8.3.20

В релизах ветки 8.3.20 (например, 8.3.20.1789) были замечены специфические баги, связанные со стабильностью конфигуратора при работе с расширениями. Это подтверждается тем, что на одной базе (рабочей) проблема может отсутствовать, а на другой (копии) — проявляться постоянно. Часто это связано с разным набором фоновых заданий, которые инициируют серверные вызовы в контексте отладки. Если серверный вызов завис или выполняется долго, предмет отладки будет оставаться активным.

Рассмотрим пример кода, который может провоцировать «зависание» серверного предмета отладки из-за длительного выполнения:

// Пример фонового задания, которое может удерживать серверный контекст отладки
Процедура ДлительнаяОперацияНаСервере() Экспорт
    // Если здесь происходит бесконечный цикл или ожидание блокировки,
    // серверный предмет отладки не исчезнет, пока задание не будет прервано.
    Для Итератор = 1 По 1000000 Цикл
        // Обработка данных
    КонецЦикла;
КонецПроцедуры

В таких случаях, прежде чем грешить на баг платформы, следует убедиться через Консоль администрирования кластеров, что в базе действительно не осталось активных или «спящих» сеансов данного пользователя. Если в консоли пусто, а в конфигураторе сеанс есть — используем описанный выше метод с кнопкой «Обновить».

Итоги

Подводя итог, можно сказать, что появление фантомных серверных сеансов — это чаще всего следствие задержки обновления интерфейса конфигуратора или специфическая ошибка работы протокола HTTP-отладки.

Основные выводы:

1. Фантомный сеанс не опасен, он лишь визуально загромождает список.
2. Для удаления достаточно нажать кнопку «Обновить» в окне выбора предметов отладки (предварительно сменив фокус или отключив/подключив любой предмет, чтобы кнопка стала активной).
3. Если проблема стала массовой, стоит проверить стабильность сетевого соединения между разработчиком и сервером dbgs.

Соблюдение этих простых рекомендаций позволит сделать процесс разработки в 1С более комфортным и предсказуемым.