Ликвидация зависшей клиентской сессии

[ASh]

Ну да..
кнопочкой "Delete Entry"

[Kir]

ASh, не вводите людей в заблуждение! Подвисает сессия между клиентской программой и сервером СУБД.

[sergsv]

Здравствуйте, Господа!


Я вынужден поднять эту тему, потому как закончилась она как-то без ответа. Ситуация с зависшим пользователем честно говоря очень неприятная, она хоть и происходит не часто, но почти всегда когда админа нет на месте.
Да и потом само решение - из-за одной зависшей сесии, чтобы он вернулся к работе- необходимо выгонять остальных человек - это не дело (Я не представляю себе как работают 20...30 и больше сметчиков %-

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

Быть может зря я тут так пыхчу, и уже есть готовое - грамотное решение или патч, ну тогда прошу подсказать адресок решения, спасибо!

Здравствуйте.

Смета.ру (5.1) сетевая.

Если у клиента зависает машина и он ее перезагружает не завершив корректно работу со сметой, то войти в смету повторно не может - "Пользователь с таким именем уже работает".
Нужно перезапустить службу Fireberd server, а перед этим выгнать всех остальных пользователей, что крайне неудобно, т.к. их десяток (сейчас).
Можно ли как-то по другому с этим бороться, а то сейчас получается что отказ одного элемента вынуждает к остановке всей системы, и чем больше клиентов, тем чаще такое будет происходить?

[Semenov]

...Меня только не устраивает что в данной ситуации "голь" - это пользователи, и почему мы должны что-то придумывать, чтобы Ваша программа корректно обрабатывала сброс зависшей сессии...

...Если у клиента зависает машина и он ее перезагружает не завершив корректно работу со сметой, то войти в смету повторно не может - "Пользователь с таким именем уже работает".
Нужно перезапустить службу Fireberd server, а перед этим выгнать всех остальных пользователей, что крайне неудобно, т.к. их десяток (сейчас).
Можно ли как-то по другому с этим бороться...

Как отмечалось ранее, сессия на сервере "зависает" (а точнее имеет место открытое TCP-соединение в режиме ожидания сигнала от инициировавшего его клиента), если
а) машина клиента "повисла" или "перезагрузилась" в результате аппаратно-программного сбоя, в т.ч. в результате нажатия на кнопку "reset", перебоев в сети питания и т.п.
б) программе не удалось продолжить работу в рамках установленного с сервером соединения по причине аппаратных сбоев в работе сети, в результате чего программа аварийно завершила работу

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

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

В помощь администратору могу предложить утилиту, которая в том числе поможет закрыть "зависшую" сессию без перезапуска СУБД Firebird и, соответственно, без прерывания работы остальных пользователей:
http://technet.microsoft.com/ru-ru/sysi ... 97437.aspx

[sergsv]

[quote="Semenov"][quote="sergsv"]
...Меня только не устраивает что в данной ситуации "голь" - это пользователи, и почему мы должны что-то придумывать, чтобы Ваша программа корректно обрабатывала сброс зависшей сессии...

[quote="boris-s"]
В данной ситуации сброс зависшей сессии на удаленном сервере - не обязанность программы, которая к тому же не имеет для этого необходимых знаний и технических возможностей, которыми должен обладать администратор сети

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

Во-первых, в решении все равно остается человек, который должен понимать, что такое TCP сессии и закрыть именно ту, которая зависла, а не откинуть что-нибудь полезное. Я же спрашивал о решении для удаленного администратора, который планово посещает налаженный в работе офис, а в свободное время работает на других объектах.

Во-вторых, решение опять из разряда моя «хата скраю…» или «спасение утопающих дело рук самих…», слава богу что есть такой продукт TCPView (Марка Руссиновича) и она подходит для нас тем что позволяет снимать сессию конкретно зависшего пользователя без перезапуска сервера «Огненной Птицы», я был бы благодарен за такое решение в интерфейсе пользователя – допустим с некими расширенными полномочиями (впрочем я бы такую возможность дал каждому работнику, чтобы каждый мог помочь соседу вернутся в работу сбросив его сессию, и если вести лог сбросов не получится использовать это свойство в корыстных целях)

А вот с этим:

>«
>Данные причины относятся не к работе программы, а к функционированию среды, >надлежащая работа которой является необходимым условием нормальной работы >программного комплекса
>В данной ситуации сброс зависшей сессии на удаленном сервере - не обязанность >программы, которая к тому же не имеет для этого необходимых знаний и технических >возможностей, которыми должен обладать администратор сети
>»

я вынужден, ну совсем не согласится!

В свою очередь я могу сказать, что в том, что отключается электричество виноват МОСЭнерго и в таком случае это не проблема системного администратора, а уже целой государственной корпорации. Оборудование которое эксплуатируется сбоит по причине того, что возможно дело в каком-то производственном браке и тут уже виноват производитель компьютера.
И т.д. можно искать виноватых бесконечно, но это не будет РЕШЕНИЕМ!!!
(К сожалению, по экономическим обстоятельствам невозможно оснастить всю сетевую активку UPSами, да и я думаю что это не решит проблемы, так как тогда нужно будет еще и на каждую рабочую станцию ставить UPS, заменить каждый компьютер на более современный и мощный, что опять таки упирается в экономическую составляющую – да и потом это опять таки решение со стороны пользователя, а не со стороны создателя комплекса, который претендует на монопольное узурпирование этого сектора ПО в России)

У нас так же как Вы полагаю, догадались, используются и иные программные продукты – это и почтовая система и различные юридические БД и везде как это не странно используется TCP/IP и нигде кроме SMETA.RU, после того как «машина клиента "повисла" или "перезагрузилась" в результате аппаратно-программного сбоя, в т.ч. в результате нажатия на кнопку "reset", перебоев в сети питания и т.п.» нет необходимости искать системного администратора, чтобы продолжить работать.

Очень хочу, чтобы Вы правильно поняли смысл моего послания, специалисты которые используют SMETA.RU я думаю уже и не представляют свою работу без этого мощного и регулярно обновляющегося комплекса, но то неудобство (должен признать, что это происходит не часто иначе думаю был бы поиск совсем другого решения), о котором идет речь несколько омрачает нашу радость от данного Российского продукта.

Спасибо за то, что дочитали до этого момента!
P/S Так много написано потому что уже давно собираюсь обойти данный негатив, но как-то все было некогда.

[sergsv]

...Меня только не устраивает что в данной ситуации "голь" - это пользователи, и почему мы должны что-то придумывать, чтобы Ваша программа корректно обрабатывала сброс зависшей сессии...

...Если у клиента зависает машина и он ее перезагружает не завершив корректно работу со сметой, то войти в смету повторно не может - "Пользователь с таким именем уже работает".
Нужно перезапустить службу Fireberd server, а перед этим выгнать всех остальных пользователей, что крайне неудобно, т.к. их десяток (сейчас).
Можно ли как-то по другому с этим бороться...

Как отмечалось ранее, сессия на сервере "зависает" (а точнее имеет

**** cut ****

В помощь администратору могу предложить утилиту, которая в том числе поможет закрыть "зависшую" сессию без перезапуска СУБД Firebird и, соответственно, без прерывания работы остальных пользователей:
http://technet.microsoft.com/ru-ru/sysi ... 97437.aspx

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

[aivt]

У нас так же как Вы полагаю, догадались, используются и иные программные продукты – это и почтовая система и различные юридические БД и везде как это не странно используется TCP/IP и нигде кроме SMETA.RU, после того как «машина клиента "повисла" или "перезагрузилась" в результате аппаратно-программного сбоя, в т.ч. в результате нажатия на кнопку "reset", перебоев в сети питания и т.п.» нет необходимости искать системного администратора, чтобы продолжить работать.

В этом я с тобой не согласен, так как знаю не мало других КЛИЕНТ-СЕРВЕРНЫХ программ, пользователи которых сталкиваются с подобной проблемой. Может быть вы не сталкиваетесь с такой проблемой в других программах, так как у вас другие программы не КЛИЕНТ-СЕРВЕРНЫЕ?

В тоже время есть КЛИЕНТ-СЕРВЕРНЫЕ программы в которых утилита администрирования показывает список пользователей и имеет напротив каждого из них кнопку "отключить", причем эта кнопка еще и работает

А пока я вам предлагаю простой выход - заведите у себя в Smeta.ru по два юзера на одного реального пользователя, например: Иванов и Иванов1. Проинструктируйте своих пользователей, что в случае наступления такой проблемы, когда программа не пускает пользователя под одним именем ему следует воспользоваться запасным именем. И не говорите, что это криво - криво наоборот, когда для решения проблемы требуется наличие системного администратора, а я предлагаю к нему в таких случаях даже не обращаться.

[Semenov]

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

Меню -> Options -> Show Unconnected Endpoints (снять галку)
если соединений по прежнему много, поможет сортировка по процессам (первая колонка, fbserver.exe)