юзера с похожими именами после разрыва коннекта

[AG]

Есть одно физ. лицо - пользователь 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 .
Предположение :
после вырубания света вполне может создаться ситуация, описанная в цитировании.

[George]

после вырубания света вполне может создаться ситуация, описанная в цитировании.

Keepalive timeout действует и на телнетовские сессии. Соединения между сервером и "погасшими" машинами закроются автоматически. А вслед за этим закроются и Progress'овые сессии. По-умолчанию timeout составляет 2 часа. Стоит задать существенно меньшее время.

Setting Keepalive to Detect Client Disconnects
http://www.sybase.com/detail?id=611

[AG]

Спасибо. Я просто предположил , вследствие чего это возникает. А проблема решается, да, тупым ожиданием .

[van]

а вот нас (linux-rh-7.1, kernel=2.4.18, progress-9.1D) "Keepalive timeout" не всегда спасает
очень редко, но случается, что как бы подвисают self-service соединения клиентов к базе в то время, как телнет-сессия уже давно умерла. да и в proshut соединения уже не наблюдается.
списке процессов системы такой процесс виден как _progress с и его особенность в том, что он очень прожорлив на процессорное время.
его можно только "кильнуть", причем далеко не через рядовой сигнал.
уж сменили три версии progress, более трех linux, а такое все-равно происходит. так и не можем понять в чем дело..
известны ли такие случаи в сообществе progress пользователей?

[George]

а вот нас (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 такой функциональности нет.

[van]

> Какой сервис-пак установлен на V9.1D? 9.1D09 выводит в лог базы > все сигналы, которые получены Progress'овой сессией, и ее реакция > на эти сигналы. Это сделано как раз в поисках возможных причин, > иногда вызывающих зацикливание процессов при отключении от > > базы. В версии 9.1E вывод такой информации можно включить > параметром -zsigdb.

у нас D01. есть уже и 9.1Е, только боевую базу так и не сподобились еще на нее перевести. в ближаюшую неделю это произойдет и тогда будем посмотреть. спасибо за подробный ответ


> В версии 10 такой функциональности нет.

только.. означает ли это, что в этой версии отпала надобность в такой функциональности..

[George]

только.. означает ли это, что в этой версии отпала надобность в такой функциональности..

Неизвестно.

9.1D09 вышла в мае 2004. 10.0B - в августе. За это время можно было разобраться и устранить проблему. Но 9.1E, вышедшая в ноябре, хоть и в скрытом виде, но содержит в себе отладочный механизм по работе с сигналами.

[svr]

Ответ на первоначальный вопрос.
Код такой (упрощенно):

Код: Выделить всё

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.

Когда у вас при выключении света подвисает юзер "q", остается залоченной запись usconf.
Процедура считает, что такой пользователь уже работает и пытается залогиниться как "q1".
Если пароли действительно совпадают, она предупреждает: "Использовано Имя q1", и в промоне будет видно подключенных "q" и "q1".
Если же пароли не совпадают, то setuserid(id + string(idnum),...) не прокатывает. И получается, что в NS2000 сеанс использует usconf от "q1", а залогинен в базу остается как "q" (см. первый setuserid в editing-цикле). И в промоне будет видно два подключения "q".
Т.о. здесь просто "небольшая" дырка в исходнике - не давайте разным людям логины, различающиеся только цифрами на конце

[van]

>а вот нас (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 вышеуказанный баг не проявляется.

[Яр]

а мы давно отключили этот кусок. Так что кому надо - тот наберет свое второе имя, и третье и тд

[van]

>4 месяца. полет нормальный.
>докладываю:
>на 9.1E01 вышеуказанный баг не проявляется.

нда.. рано я обрадовался
за 2 месяца уже 2 инцидента есть.
т.е. причина осталась, но проявления стали реже.
похоже, ее надо в коде искать, а не в субд