Обработка предназначена для автоматического завершения неактивных и зависших сеансов на кластере сервера 1С. Есть возможность настроек.
Для старта необходимо в закладке: Настройки
1. Указать имя сервера и базы данных
2. Имя пользователя и пароль для доступа к кластеру сервера (если нет пользователя, нужно создать через консоль сервера 1С)
3. В левой таблице необходимо указать, какие приложения будут проверяться (если не указать, проверяться не будет):
- фоновые задания
- конфигуратор
- толстый клиент
- тонкий клиент
- web клиент
и указать для каждой настройки:
- колонка «Дубли» — это поиск задвоенных сеансов от одного и тогоже пользователя, очень часто встречается у Web клиента. Отключаются задвоенные сеансы, остается один последний по активности.
- колонка «Простой» — это количество секунд простоя сеанса, при привышении, отключение.
4. Указать пользователей по которым проверки не будет (для администраторов и др.)
5. На закладке «Монитор» нажать «Старт», обработка будет работать автоматически.
6. На закладке «История» фиксируются отключения сеансов (дубли или простой)
А сообщения можно отправлять пользователям перед их выключением?
Идея хорошая, вопрос только как вы определяете что сеанс завис?
Или это ручная работа по определению?)
Добрый день! Мне кажется можно отследить — делает ли пользователь за определенный период какие либо действия или нет. Подводные камни в данном случае — регламентные или фоновые задания под этим пользователем. Но если еще и брать в расчет, что кроме Р иФ делает ли пользователь что-нибудь, если нет — рубить сплеча! Незачем базу излишне держать!
(1) нет такой возможности, потому что завершаемые сеансы в 99% случаев, это зависшие сеансы, поэтому, даже если придумать сообщение, его никто не увидит.
(2) Два варианта:
1 — простой, по превышении лимита времени, сеанс приложения (Web клиент из настроек) завершается.
2 — программа смотрит, есть ли еще сеансы под этим пользователем, активность которых остановилась. Это в основном происходит у Web клиентов, т.е. обновили страницу сайта и всё, подключение уходит в «дубль» и висит неактивное, а тут же запускается новый сеанс, соответственно уже две лицензии 1С.
Данная обработка используется, чтобы лицензии выданные на сеанс не «висели в воздухе». При большом количестве web юзеров, лицензии кушаются на ура.
(3) В настройках можно указать, чтобы проверялись только к примеру Web клиенты, фоновые и другие приложения будут пропускаться. У Сеанса есть «последняя активность» это ключевой параметр, от него можно и плясать.
(5) я понял, значит ручками. У меня другой интерес был, там где действительно сеанс завис и вы сразу его отключили!
Прикольно конечно! Я в свое время с висляками боролся т.к. в базе много народу и порой забивало сессиями количество лицензий. Лечил следующим образом:
1. Вычислил начало работы первого юзера и последнего — филиальная система — от Хабаровска до Калининграда.
2. Приблизительно вычислил окно бездействия сервера.
3. в Планировщик задач поставил перезапуск Агента 1С_сервера.
лекарство действует)
(7) что ручками, не пойму?
(8) Перезапуск агента, это как лодку под рыбаками поменять быстро. А отбивание сеансов средствами кластера сервера, почему не применялось? Бывают конечно сеансы, которые застревают намертво, тут только перезапуск агента.
(10) нет, достаточно перевести на другой рхост.
(9) килять процес, который действительно завис, а не неактивен или запущен второй сеанс. Ваш вариант очень прост и для меня мало интересен.
Баян.
Баян не Баян, а ленивому на руки.
Сработало )
Однако хорошо бы не быть чувствительным к регистру названия ИБ. А то пришлось отладчиком разгадывать, почему при зареганной базе «base1C» к «base1c» не подключается.
Обработка работает только при запущенном клиенте?
Да, чтобы конфигурацию не менять (регламентные задания).
Агент.Authenticate(Кластер, Пользователь, Пароль);
по причине:
Произошла исключительная ситуация: Ошибка операции администрирования
Администратор кластера не аутентифицирован
(18) Тоже скачал. А нифига не работает.
😀 Ура! Работает!