В процессе разработки конфигураций на платформе 1С:Предприятие 8.3 многие разработчики сталкиваются с неприятным поведением отладчика: во время выполнения кода точка останова на клиенте срабатывает стабильно, но серверные вызовы внезапно перестают перехватываться. При этом в диалоге доступных предметов отладки клиентское приложение остается подключенным, а серверные сеансы бесследно исчезают. Приходится перезапускать сеанс отладки, что существенно снижает скорость разработки. Разберем подробно, почему это происходит и как устранить проблему.
Проанализируем механику работы отладчика по умолчанию. В классическом протоколе отладки (TCP/IP) соединение между конфигуратором и рабочим процессом rphost является прямым полнодуплексным сокетом в диапазоне рабочих портов (по умолчанию 1560–1591). Если в кластере серверов 1С происходит любое событие, приводящее к смене рабочего процесса — например, аварийное завершение процесса rphost, динамическая балансировка нагрузки или плановый перезапуск по лимитам памяти, — клиентский сеанс пользователя прозрачно переподключается к другому живому процессу rphost. Пользователь даже не замечает сбоя. Однако отладчик по протоколу TCP не умеет автоматически восстанавливать сессию на новом сокете другого процесса: серверная отладка безвозвратно теряется.
Выясним причину аварийного завершения процессов rphost. Для этого настроим сбор технологического журнала на сервере 1С. Создадим минимальный файл конфигурации logcfg.xml в каталоге настроек платформы для отслеживания аварийных ситуаций:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\Crash" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
События EXCP (исключения) и PROC (запуск и завершение процессов кластера) позволят точно определить, перезапускался ли rphost в момент исчезновения серверных точек останова.
Как показывает практика, частыми виновниками внезапного падения процесса rphost выступают внешние библиотеки и аппаратные проблемы:
0xC0000005) внутри сторонней динамической библиотеки мгновенно завершают весь процесс rphost, не оставляя записей в обычном журнале регистрации 1С. В этом случае обновите компоненту печати штрихкодов до актуальной версии или перенесите вызовы генерации ШК в изолированные клиентские процедуры либо отдельные фоновые задания.rphost, что вызывает падение процесса при интенсивных операциях. Протестируйте модули памяти специализированными утилитами.Наиболее надежный архитектурный способ победить разрывы отладки в платформе 1С 8.3 — переключиться с устаревшего протокола TCP на современный отладочный протокол HTTP. В этом режиме взаимодействие отладчика с процессами сервера маршрутизируется через специальный сервер отладки dbgs, что делает сессию устойчивой к миграциям контекста между процессами кластера.
-debug -http, либо запустим отдельный экземпляр утилиты dbgs с указанием адреса кластера.Если разработка ведется на общем сервере, стандартные механизмы самовосстановления кластера могут принудительно гасить процессы, в которых идет отладка. Проверим и скорректируем параметры в консоли кластера 1С:
0 (отключить плановый перезапуск).rphost рекомендуется зафиксировать выделение одного постоянного рабочего процесса на базу.Если перенастройка сервера временно недоступна, применим оперативное решение прямо в конфигураторе:
Благодаря этой настройке конфигуратор будет пытаться перехватывать новые серверные соединения, возникающие при последующих вызовах с клиента, даже если предыдущий процесс rphost аварийно завершился. Если отладка все же отключилась, достаточно в диалоге Отладка → Подключение отключить оставшийся сеанс клиента и подключить его заново вместе с обнаруженными серверами, избегая полного перезапуска программы.