Доброго дня
Подскажите, можно ли получить доступ к сеансам пользователей на сервере (с целью удаления неактивных) Без КОМконнектора? По выбранному варианту реализации нужно проверить при входе в базу наличие сеансов для текущего пользователя текущей базы и удалить те, что были подняты раньше. Такой вариант подразумевает безусловный подъем коннектора, что занимает время, чего не хотелось бы.

платформа 8.2.19

(0) А как вы предлагаете удалять сеансы без коннектора?

(2) я и не предлагаю, а спрашиваю, есть ли варианты)

(3) имхо придется все равно цепляться к кластеру по ком и управлять сеансами. По поводу активный/не активный сеанс вы вряд ли легко определите. Человек может отойти на несколько часов от компа с открытой 1ски, а сеанс его будет активным, так как 1ска оперативно отвечает на запросы кластера.

https://its.1c.ru/db/v8322doc#bookmark:cs:TI000000257
АдминистрированиеСеанс (AdministrationSession).
ЗавершитьСеанс (TerminateSession).
Синтаксис:
ЗавершитьСеанс(<СообщениеОбОшибке>)
Параметры:
<СообщениеОбОшибке> (необязательный).
Тип: Строка.
Сообщение для пользователя, которое содержит причину завершения сеанса.
Описание:
Удаляет сеанс. Попытка обращения к кластеру серверов от имени удаленного сеанса вызывает исключение.
Доступность: Тонкий клиент, сервер, толстый клиент, интеграция.
Использование в версии: Доступен, начиная с версии 8.3.14.

https://its.1c.ru/db/v8322doc#bookmark:adm:TI000001112

(4) или так: для начала понять, есть ли то, что удалять, чтобы без КОМа, и если есть то только потом его поднимать. условия необходимости удаления сеанса тут я упрощаю, есть набор условий (именно активность - согласен, косвенный признак)

(5) "Использование в версии: Доступен, начиная с версии 8.3.14. "-> (1) платформа 8.2.19

(5) да видел, но с 8.3.14, прогресс в этом направлении радует конечно, но не всегда

(5) интересно.. если из базы на 8.2 через сервис отдать данные запускаемого сеанса в базу на 8.3 (сервер приложения есть обоих версий) и там анализировать и удалять.. взлетит? в (5) это быстро работает? имею ввиду, не поднимается ли там тот же ком, только скрыто/неявно, сервером приложения?

(9) А вы видите в данном методе возможность указать конкретный сеанс? Да даже если и была возможность, имхо не взлетело бы. Вы бы передали данные сеанса в другую базу, а ей потом что делать, когда у нее нет доступа в кластеру платформы 8.2?

(0) Установи консоль администрирования сразу же, чтобы не устанавливать по мере необходимости. На мой взгляд, остальное - не оптимально

(10) н да..
(11) чем поможет консоль, не понял, руками удалять?

(11) запускать ее батником с параметрами или что?

(12) если сеанс "завис" наглухо, то из консоли может не удаляться, так же как и "зависшие" фоновые задания.

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

+(14) это если консоль администрирования клистера 1С не помогает, а агента сервера 1С нельзя ребутать, ибо работают люди...

(14) (15) Ага, только на этом рпхосте могут быть еще Nое количество работающих юзверов))

(12) Конечно, руками. Я не представляю ситуацию, когда процесс убивания настолько часто нужен, чтобы этот процесс автоматизировать.

(17) Встречал на одном оптовом предприятии следующую реализацию: каждую ночь убивались все сеансы и перезагружалась служба 1с, вроде еще кэш чистили и все это по крону отрабатывало. На утро никаких зависших сеансов, все знают, что оставлять включенную 1ску не надо.

(18) в настройках раб.процессов можно настроить интервал перезапуска и ограничение по памяти, чтобы ребутался? тогда все активные сеансы мигрируют на другие менее загруженные рпхосты и чисто конкретный рпхост ребутается

(19) " тогда все активные сеансы мигрируют на другие менее загруженные рпхосты" - а вы даете 100% гарантию, что вводимые данные не пропадут у юзвера, когда ему рпхост грохнут и он успешно перекинется на новый рпхост?)

(14) да, но это другая часть проблемы. первый вариант - когда из консоли можно прибить сеанс, но что бы не руками там лазить, т к известно становится что какой то из сеансов повис, только тогда, когда появляются явные проблемы, вроде блокировки документов, таблиц и тд
+ возможность плодить сеансы пользователем тоже надо убрать

возможный вариант, как считаю: при входе в базу смотрим наличие сеансов от этого пользователя/компа в базе и если есть более "старшие" сеансы, то пробуем их удалить, с оповещением пользователя конечно, типа "у вас уже запущено, если хотите войти в этом окне, тогда другое будет закрыто автоматически, да?". Удаляем предыдущие. Да, могут быть глухие сеансы, но это уже другая часть вопроса, о которой можно так же админам кинуть на почту, что есть сеанс, который удалить не вышло, подумайте об этом. И они уже перегрузят Агента (если только кто нибудь не подскажет, что с такими сеансами кроме перегрузки службы можно еще сделать)

(17) у нас контроль запуска базы по несколько раз + попробовать не допустить зависших

(20) в общем я к тому, что лучше глянуть кто еще на этом рпхосте висит и предупредить этих юзверов, чтобы сохранили свои данные

(18)(19) у нас круглосуточная работа. грохать рпхост не вариант, да и потом - ни кто не гарантирует, что свежий сеанс не может повиснуть через 10 минут после начала

(23) А из-за чего у вас сеансы виснут? Сколько у вас пользователей одновременно работает?

(24) около 500, я думаю что скл косячит, админы так не считают

(25) У вас КОРП лицензия я надеюсь?)

(26) да. админы все время переоформляют то одно то другое, актуальной ситуации не знаю, проблемы тоже есть. это еще один из вопросов, который станет проще, если дубли сеансов предупредить

(21) с учетом того, что разработчики типовых баз любят использовать подписки на события - вряд ли вы программно отличите открытый сеанс от глухого

(28) да, понятно, поэтому нужно бороться с причиной появления висячих сеансов. при входе посмотрели, удалили все, кроме текущего. если повис, то пользователь перезапускает и опять смотрим/удаляем. глухих не удалили - оповестили заинтересованных.

(29) + то есть отдать на откуп пользователю

все это хорошо, напрягает только время подъема кома к агенту

(30) Вам бы по уму разобраться в причине зависания клиентов, а так это просто очередной костыль...Есть возможность протестировать работу на новой платформе? Может релиз глючный под такую нагрузку?

(31) хрен знает... вот ситуация: открываю док, меняю - "объект заблокирован, сеанс номер.., пользователь..". Тут же + - понимаю, что внешняя софтина, которая грузит данные в базу напрямую ничего не грузит. Ковыряюсь что бы понять почему, ни виходит, ни панятна. Ладно, разберемся сначала с псевдосеансом... Открываю активных пользователей, там нет такого сеанса. Консоль, нашли, прибили - документ отпустило, софтина тоже заработала. То есть блокировка записей/таблиц скл, причем сеансом, который к таблицам внешней софтины отнощения не имеет. С ними собственно на запись только она и работает. Внимание, вопрос!?))

(32) Значит нужно с блокировками вопрос решать, у вас там управляемые блокировки?

дело в том, что этой проблеме с повисшими сеансами много лет, сколько помню всегда это было, то так виснут то так, то еще как то, разные варианты. Уже устойчивый стереотип, что связка сервер приложения + скл так и работает, это норма(с). Раньше были другие платформы, старшие, теперь эта, но проблемы идентичные. Хотя как вариант может предложить админам поставить посвежее 8.2. но сомнительно как то, что поможет.
пс. подписки/кривые коды вроде циклов без конца не рассматриваем - изучали, смотрели, криминала не найдено. При этом в момент висяка на скл (а бывает и такое, SDBL и остальное) админ присылает склный запрос и говорит - вот повесивший сервер запрос, смотрим - банальная выборка, простейший запрос. Да, данных в выборку попадает много, но с этим ничего не сделаешь, реальные данные, реальный "полезный" объем. А значит что? А значит производительность железа страдает. Админ отпирается, что на этом железе все должно летать, у вас код кривой. Даже как то предъявил, в контексте там тратата, спор да дело "ага, понятно - кривая реализация бегущей строки". Бегущей строки, Карл! кривая реализация млять. Криво нажали галку "БС" в свойствах надписи, ага. Ладно, лирика пошла.

(33) автоматический и управляемый

(34) "банальная выборка, простейший запрос" - выборка-то может быть банальная, только таблица в выборке уже залочена другим сеансом, который возможно что-то писал в эту таблицу через какое-нибудь ком соединение и повис. У вас вообще как с обменами через ком, популярная тема?

(35) это не про повисший сеанс, а про тормоза на скл. это приводит к "ошибка блокировки данных SDBL" на скл.
обмены идут, в основном сервисы, но есть некоторый функционал оставшийся на комах.

да не озадачивайтесь, слишком много разного функционала, гадать с поиском причин не получится. Явного (вопиющего) косяка быть не должно, все более менее грамотные - и админы и проги

+ 36 да, ошибка блокировки может как следствие привести к потухшему сеансу, но если его не трогать(консоль, ctrl/alt/del на клиенте или еще как), то он отвиснет когда сервер просрется и выдаст результат. как мне кажется это только вопрос производительности сервера. нужен контроль количества сеансов от одного и того же пользователя ввиду подчистки предыдущих его сеансов (повисших и неповисших, нех одно и то же по несколько раз запускать), контроля использованных лицензий

(37) "то он отвиснет когда сервер просрется и выдаст результат" - не факт, может быть таймаут по истечению которого просто вывалится с ошибкой мол конфликт блокировок и ошибка скуля.

(38) ну да, или так. тем не менее сеанс останется живой

в целом тут КОМ работает не так медленно, пойдет