юзера с похожими именами после разрыва коннекта
Сообщений: 11
• Страница 1 из 1
юзера с похожими именами после разрыва коннекта
Есть одно физ. лицо - пользователь NS - у него 2 логина под именами
user и user1 - то есть они во всем (правах фамилиях и так далее) одинаковы , только отличаются на 1 букву. Так вот зачем-то, сессия
user лочит запись userconf WHERE userconf.user-id = "user1" .
и получается, что user1 войти в систему не может. Описаная ситуация - ситуация после вырубания света.
Сразу говорю , что main.p у меня в исходниках нет , а потому для меня это было новшеством.
Дано:
в ns2000 заведено 2 пользователя
a) q с паролем z
b) q1 с паролем z
оба на одного юзера, на одну группу и так далее .
Ход задачи :
заходит в нс-ку user q с логином q и паролем z. Далее ,
он же запускает новую нс-ку, с ТАКИМ ЖЕ логином и паролем и main.p
его пропускает , причем дает ему user-id = q1 , например userconf (или подобную таблицу настроек юзера ) where userconf.user-id = q1 .
Итог:
в нс-ке светится 2 работающих юзера q и q1.
в progresse - 2 сессии с юзером q .
Предположение :
после вырубания света вполне может создаться ситуация, описанная в цитировании.
Re: юзера с похожими именами после разрыва коннекта
AG писал(а):после вырубания света вполне может создаться ситуация, описанная в цитировании.
Keepalive timeout действует и на телнетовские сессии. Соединения между сервером и "погасшими" машинами закроются автоматически. А вслед за этим закроются и Progress'овые сессии. По-умолчанию timeout составляет 2 часа. Стоит задать существенно меньшее время.
Setting Keepalive to Detect Client Disconnects
http://www.sybase.com/detail?id=611
а вот нас (linux-rh-7.1, kernel=2.4.18, progress-9.1D) "Keepalive timeout" не всегда спасает
очень редко, но случается, что как бы подвисают self-service соединения клиентов к базе в то время, как телнет-сессия уже давно умерла. да и в proshut соединения уже не наблюдается.
списке процессов системы такой процесс виден как _progress с и его особенность в том, что он очень прожорлив на процессорное время.
его можно только "кильнуть", причем далеко не через рядовой сигнал.
уж сменили три версии progress, более трех linux, а такое все-равно происходит. так и не можем понять в чем дело..
известны ли такие случаи в сообществе progress пользователей?

очень редко, но случается, что как бы подвисают self-service соединения клиентов к базе в то время, как телнет-сессия уже давно умерла. да и в proshut соединения уже не наблюдается.
списке процессов системы такой процесс виден как _progress с и его особенность в том, что он очень прожорлив на процессорное время.
его можно только "кильнуть", причем далеко не через рядовой сигнал.
уж сменили три версии progress, более трех linux, а такое все-равно происходит. так и не можем понять в чем дело..
известны ли такие случаи в сообществе progress пользователей?
van писал(а):а вот нас (linux-rh-7.1, kernel=2.4.18, progress-9.1D) "Keepalive timeout" не всегда спасает
очень редко, но случается, что как бы подвисают self-service соединения клиентов к базе в то время, как телнет-сессия уже давно умерла. да и в proshut соединения уже не наблюдается.
Думаю сценарий такой: Keepalive процесс заметил, что по открытому сокету давно ничего не передавалось, и послал на тот конец "трубы" несколько пробных пакетов, но поскольку телнетовская сессия завершилась аварийно, то никто не откликнулся. Тогда keepalive процесс закрыл сокет и послал HANGUP сигнал всем процессам, порожденным в рамках этого соединения. Progress'овый процесс отключился от базы и после этого должен был завершиться.
списке процессов системы такой процесс виден как _progress с и его особенность в том, что он очень прожорлив на процессорное время.
его можно только "кильнуть", причем далеко не через рядовой сигнал.
Но что-то внутри Progress'овой сесси пошло криво и он зациклился. Это объясняет почему процесс пожирает CPU. Процесс реагирует не на все сигналы потому, что при критически важных операциях некоторые сигналы игнорируются. Какие сигналы и когда они игнорируются подробно описано в статье KB-P67938:
How Progress interprets and handles kill Signals
уж сменили три версии progress, более трех linux, а такое все-равно происходит. так и не можем понять в чем дело..
известны ли такие случаи в сообществе progress пользователей?
Известны также и исправления для проблем с подобными симптомами. Причин может быть много. Возможно не все исправили.
Какой сервис-пак установлен на V9.1D? 9.1D09 выводит в лог базы все сигналы, которые получены Progress'овой сессией, и ее реакция на эти сигналы. Это сделано как раз в поисках возможных причин, иногда вызывающих зацикливание процессов при отключении от базы. В версии 9.1E вывод такой информации можно включить параметром -zsigdb. В версии 10 такой функциональности нет.
> Какой сервис-пак установлен на V9.1D? 9.1D09 выводит в лог базы > все сигналы, которые получены Progress'овой сессией, и ее реакция > на эти сигналы. Это сделано как раз в поисках возможных причин, > иногда вызывающих зацикливание процессов при отключении от > > базы. В версии 9.1E вывод такой информации можно включить > параметром -zsigdb.
у нас D01. есть уже и 9.1Е, только боевую базу так и не сподобились еще на нее перевести. в ближаюшую неделю это произойдет и тогда будем посмотреть. спасибо за подробный ответ
> В версии 10 такой функциональности нет.
только.. означает ли это, что в этой версии отпала надобность в такой функциональности..
у нас D01. есть уже и 9.1Е, только боевую базу так и не сподобились еще на нее перевести. в ближаюшую неделю это произойдет и тогда будем посмотреть. спасибо за подробный ответ
> В версии 10 такой функциональности нет.
только.. означает ли это, что в этой версии отпала надобность в такой функциональности..
van писал(а):только.. означает ли это, что в этой версии отпала надобность в такой функциональности..
Неизвестно.
9.1D09 вышла в мае 2004. 10.0B - в августе. За это время можно было разобраться и устранить проблему. Но 9.1E, вышедшая в ноябре, хоть и в скрытом виде, но содержит в себе отладочный механизм по работе с сигналами.
Ответ на первоначальный вопрос.
Код такой (упрощенно):
Процедура считает, что такой пользователь уже работает и пытается залогиниться как "q1".
Если пароли действительно совпадают, она предупреждает: "Использовано Имя q1", и в промоне будет видно подключенных "q" и "q1".
Если же пароли не совпадают, то setuserid(id + string(idnum),...) не прокатывает. И получается, что в NS2000 сеанс использует usconf от "q1", а залогинен в базу остается как "q" (см. первый setuserid в editing-цикле). И в промоне будет видно два подключения "q".
Т.о. здесь просто "небольшая"
дырка в исходнике - не давайте разным людям логины, различающиеся только цифрами на конце 
Код такой (упрощенно):
- Код: Выделить всё
update id password editing:
...
if not setuserid(id,password,g_user_base_name) then do:
run _warn.p ("Неверное имя или пароль.").
next.
end.
end.
do transaction:
find usconf where usconf.user-id = id use-index user-ind exclusive-lock no-wait no-error.
end.
idnum = 0.
fnd-id:
do while locked usconf transaction:
idnum = idnum + 1.
find usconf where usconf.user-id = id + string(idnum) use-index user-ind exclusive-lock no-wait no-error.
if available usconf then do:
if setuserid (id + string(idnum),password,g_user_base_name) then do:
id = id + string(idnum).
run _warn.p ("Использовано Имя " + id).
leave fnd-id.
end.
end.
else
if not locked usconf then do:
bell.
run _warn.p ( "Пользователь с Вашим именем уже работает в системе.^Работа с одинаковыми именами запрещена." ).
...
end.
end.
Процедура считает, что такой пользователь уже работает и пытается залогиниться как "q1".
Если пароли действительно совпадают, она предупреждает: "Использовано Имя q1", и в промоне будет видно подключенных "q" и "q1".
Если же пароли не совпадают, то setuserid(id + string(idnum),...) не прокатывает. И получается, что в NS2000 сеанс использует usconf от "q1", а залогинен в базу остается как "q" (см. первый setuserid в editing-цикле). И в промоне будет видно два подключения "q".
Т.о. здесь просто "небольшая"


>а вот нас (linux-rh-7.1, kernel=2.4.18, progress-9.1D) "Keepalive >timeout" не всегда спасает
>очень редко, но случается, что как бы подвисают self-service >соединения клиентов к базе в то время, как телнет-сессия уже >давно умерла. да и в proshut соединения уже не наблюдается.
> Какой сервис-пак установлен на V9.1D? 9.1D09 выводит в лог базы > все сигналы, которые получены Progress'овой сессией, и ее реакция > на эти сигналы. Это сделано как раз в поисках возможных причин, > иногда вызывающих зацикливание процессов при отключении от > > базы.
>В версии 9.1E вывод такой информации можно включить > параметром -zsigdb.
>у нас D01. есть уже и 9.1Е, только боевую базу так и не >сподобились еще на нее перевести. в ближаюшую неделю это >произойдет и тогда будем посмотреть.
4 месяца. полет нормальный.
докладываю:
на 9.1E01 вышеуказанный баг не проявляется.
>очень редко, но случается, что как бы подвисают self-service >соединения клиентов к базе в то время, как телнет-сессия уже >давно умерла. да и в proshut соединения уже не наблюдается.
> Какой сервис-пак установлен на V9.1D? 9.1D09 выводит в лог базы > все сигналы, которые получены Progress'овой сессией, и ее реакция > на эти сигналы. Это сделано как раз в поисках возможных причин, > иногда вызывающих зацикливание процессов при отключении от > > базы.
>В версии 9.1E вывод такой информации можно включить > параметром -zsigdb.
>у нас D01. есть уже и 9.1Е, только боевую базу так и не >сподобились еще на нее перевести. в ближаюшую неделю это >произойдет и тогда будем посмотреть.
4 месяца. полет нормальный.
докладываю:
на 9.1E01 вышеуказанный баг не проявляется.
Сообщений: 11
• Страница 1 из 1
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1