При работе с 1С через веб-клиент или тонкий клиент по HTTP-протоколу системные администраторы часто сталкиваются с проблемой «брошенных» сеансов. Ситуация классическая: пользователь редактировал важный документ или карточку справочника, после чего его компьютер внезапно перезагрузился или пропал интернет. Веб-сервер (Apache или IIS) продолжает считать это соединение активным, а информационная база удерживает объектную блокировку, не позволяя другим сотрудникам вносить изменения. Перезагрузка всего веб-сервера — мера радикальная, так как она прервет работу всех остальных активных пользователей. Разберем детально, как можно решить эту проблему более тонкими методами.
В клиент-серверном варианте (SQL) управление сеансами берет на себя кластер серверов 1С, и администратор может легко «выбить» любого пользователя через консоль. В файловом режиме при публикации через веб-сервер роль «клиента» для базы данных 1Cv8.1CD выполняет процесс самого веб-сервера (например, httpd.exe для Apache). Когда реальный физический клиент отключается некорректно, веб-сервер не сразу узнает об этом и продолжает удерживать контекст сессии в памяти.
Рассмотрим штатное поведение системы: по умолчанию в платформе 1С установлен тайм-аут неактивности сеанса, равный 20 минутам (1200 секунд). Если в течение этого времени от браузера или тонкого клиента не поступит ни одного запроса, сервер приложений 1С внутри веб-сервера закроет сеанс и освободит все блокировки. Однако ждать 20 минут в условиях интенсивной работы склада или бухгалтерии часто невозможно.
Проанализируем файл дескриптора публикации default.vrd. Этот файл находится в каталоге, куда вы публиковали базу (например, C:\inetpub\wwwroot\MyBase или /var/www/html/MyBase). Мы можем принудительно ограничить время, через которое «заснувший» сеанс будет терминирован. Для автоматической проверки параметров default.vrd и веб-сервера можно использовать инструмент для аудита настроек веб-публикации.
Для этого в разделе <point> добавим специальные атрибуты. Посмотрим на пример конфигурации:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/MyBase"
ib="File="C:\Bases\Trade";"
sessionMaxAge="600">
<ws>
<point name="WebServiceName"
alias="ws1.1cws"
poolTimeout="300" />
</ws>
</point>
Разберем параметры, которые мы использовали:
600 (10 минут), мы заставим сервер очищать зависшие подключения в два раза быстрее, чем по умолчанию.Мало кто знает, что даже в файловой базе можно программно получить список сессий и программно же их завершить, не имея под рукой консоли администрирования. Мы можем создать небольшую обработку, которая позволит администратору под своей учетной записью «выкинуть» зависшего коллегу. Для решения этой задачи без самостоятельной разработки можно использовать готовое расширение для принудительного завершения работы пользователей.
Рассмотрим пример кода, который возвращает список активных сеансов:
СеансыИнфоБазы = МенеджерСеансовИнформационнойБазы.ПолучитьСеансыИнформационнойБазы();
Для Каждого ТекущийСеанс Из СеансыИнфоБазы Цикл
Сообщить("Пользователь: " + ТекущийСеанс.Пользователь.Имя + " | Начало: " + ТекущийСеанс.НачалоСеанса);
КонецЦикла;
Для принудительного завершения конкретного сеанса (например, если мы определили его по имени пользователя или номеру сеанса), используем метод ЗавершитьСеанс(). Это самый эффективный способ решить проблему без перезагрузки служб. Разберем фрагмент кода:
// Предположим, мы нашли нужный сеанс в массиве
Попытка
ЗавершитьСеанс(ВыбранныйСеанс);
Сообщить("Сеанс успешно завершен, блокировки должны быть сняты.");
Исключение
Сообщить("Не удалось завершить сеанс: " + ОписаниеОшибки());
КонецПопытки;
Важно: для выполнения этих действий у пользователя должны быть полные права (Административные функции).
Иногда сессия «висит» из-за того, что само TCP-соединение между клиентом и веб-сервером не разрывается. Выясним причину на уровне настроек Apache или IIS.
Если вы используете Apache, обратите внимание на параметры в файле httpd.conf:
KeepAliveTimeout — установите значение 5–15 секунд. Если клиент внезапно исчез, сервер быстрее закроет сокет.MaxKeepAliveRequests — ограничьте количество запросов в рамках одного соединения.В случае с IIS, проверьте настройки в диспетчере служб: выберите ваш сайт -> "Пределы" (Limits) -> "Тайм-аут подключения" (Connection Timeout). Уменьшение этого значения поможет серверу быстрее высвобождать ресурсы рабочего процесса w3wp.exe.
В современных версиях платформы реализован механизм «перехвата» сеанса. Если пользователь, чей сеанс «завис», попробует снова зайти в базу под тем же логином и с того же устройства (браузера), система предложит восстановить соединение или завершить предыдущий сеанс. Это происходит автоматически благодаря улучшенному управлению контекстом в snccntx (папка контекста сеансов).
Проанализируем также папку информационной базы. Если ситуация критическая и ничего не помогает, в файловом варианте за информацию о сессиях отвечают временные файлы в подкаталоге базы. Однако их удаление вручную возможно только при полностью остановленном веб-сервере, что возвращает нас к исходному ограничению, поэтому программный метод через ЗавершитьСеанс() остается приоритетным.
Подводя итог, для борьбы с зависшими сессиями в файловой 1С через веб без перезагрузки всего сервера рекомендуем придерживаться следующего алгоритма:
ЗавершитьСеанс().sessionMaxAge в файле default.vrd до приемлемых 5-10 минут (300-600 секунд).