[Sqlrelay-discussion] Extended signal handling in connections (patch)
Brought to you by:
mused
|
From: Renat S. <sr...@st...> - 2010-07-09 09:37:13
|
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... |