[Sqlrelay-discussion] Extended signal handling in connections (patch)

[Renat S. <sr...@st...>]

Hello David and others.

When signal is received (SIGALRM, SIGTERM or any other), sqlr-connection 
should delete pid file, disconnect from DB and modify statistics in shm 
to tell scaler and listener that it is about to die. I noticed that 
sometimes sqlr-connection dies without cleaning up, therefore I made a 
patches to rudiments and sqlrelay which do several things:

1) Signal handling setup was moved from main.C of particular connection 
to method of connection class

2) Connection now catch all signals but SIGKILL and SIGSEGV. SIGKILL is 
not able to be caught. SIGSEGV is not caught because usually we want to 
examine core dump in case of segmentation violation.

3) Daemon class in rudiments uses signal handler with int parameter 
(signal number) if it is possible

4) Connection exits with code 0 if there is no errors happenes or code 1 
if error is detected

5) oracle connection has got extended signal handler, which exits with 
code 0 or 1 in case of expected or unexpected signals.

6) When scaler is started with option "-fork", it writes to stderr 
reason why connection was terminated, for example
Connection (pid=17564) exited with code 1
Connection (pid=10898) terminated by signal 11

Patch to rudiments is named 02_signal_handling_int.patch
Patch to sqlrelay is named 15_connection_handle_signals.patch

After all, I found that sometimes connection catch signal 11 (SIGSEGV) 
with this debug ending:

done getting command
getting a cursor...
found a free cursor:
1
done getting a cursor
new query
handling query...
getting query...
querylength:
106
query:
select check_user_profile(1843) fin, check_user_profile(2502) tech, 
check_user_profile(4122) uni from dual
getting query succeeded
getting input binds...
done getting input binds
getting output binds...
done getting output binds
getting send column info...
send column info
done getting send column info...

The ending is always the same, and this happens occasionly. Indeed, this 
log means that sqlr-connection dies somewhere in 
oracle8cursor::cleanUpData. Have anyone met this kind of problems?

-- 
Renat Sabitov   e-mail: sr...@st...
Stack Soft         jid: sr...@ja...