Hi,
looking at the code, the server return SQL_DOWN if there is any type of error.
Errors like "ORA-01401: inserted value too large for column" are set by the Oracle server, so the server is up and running.
In this situation it's not a good idea to reconnect the socket.
Performing some tests, I found two specific errors that mean "database down": ORA-03113 and ORA-03114.
So I wrote a new function, sql_check_error (like the mysql one), that checks the error code and return SQL_DOWN or -1.
I don't know if this solve the bug, but surely it manages better the query.
In this patch I set the "commit on success".
--- src/modules/rlm_sql/drivers/rlm_sql_oracle/sql_oracle.c.orig 2004-08-12 12:57:50.320339000 +0200
+++ src/modules/rlm_sql/drivers/rlm_sql_oracle/sql_oracle.c 2004-09-04 17:49:29.388796000 +0200
@@ -73,6 +73,25 @@
}
}
+/************************************************************************* + * + * Function: sql_check_error + * + * Purpose: check the error to see if the server is down + * + *************************************************************************/ +static int sql_check_error(SQLSOCK *sqlsocket, SQL_CONFIG *config) { + + if (strstr(sql_error(sqlsocket, config), "ORA-03113") || + strstr(sql_error(sqlsocket, config), "ORA-03114")) { + radlog(L_ERR,"rlm_sql_oracle: OCI_SERVER_NOT_CONNECTED"); + return SQL_DOWN; + } + else { + radlog(L_ERR,"rlm_sql_oracle: OCI_SERVER_OK"); + return -1; + } +}
/************************************************************************* * @@ -244,22 +263,20 @@ (ub4) 0, (OCISnapshot *) NULL, (OCISnapshot *) NULL, - (ub4) OCI_DEFAULT); + (ub4) OCI_COMMIT_ON_SUCCESS);
- if ((x != OCI_NO_DATA) && (x != OCI_SUCCESS)) {
- radlog(L_ERR,"rlm_sql_oracle: execute query failed in sql_query: %s",
- sql_error(sqlsocket, config));
- return SQL_DOWN;
+ if (x == OCI_SUCCESS) {
+ return 0;
}
- x = OCITransCommit(oracle_sock->conn, oracle_sock->errHandle, (ub4) 0);
- if (x != OCI_SUCCESS) {
- radlog(L_ERR,"rlm_sql_oracle: commit failed in sql_query: %s",
+ if (x == OCI_ERROR) {
+ radlog(L_ERR,"rlm_sql_oracle: execute query failed in sql_query: %s",
sql_error(sqlsocket, config));
- return SQL_DOWN;
+ return sql_check_error(sqlsocket, config);
+ }
+ else {
+ return -1;
}
-
- return 0;
}
At 15.27 03/09/2004, you wrote:
OK, it seems bugs.freeradius.org is experiencing problems. I submit the bug here with the corresponding debugging outputs. When the problems are restored, I will submit it in bugs also...
Short Description: Freeradius crashes upon oracle errors in accounting queries
Way to reproduce: Run radiusd -X and from a shell
for ((i=0;$i<30; i=$i+1)); do radclient -d ~/freeradius/BUILD/etc/raddb/ -f testacct localhost acct testing123; sleep 2; done
testacct file: User-Name = kzorbatest Acct-Session-Id = 123456789009876543211234567890ABCDEFGHI NAS-IP-Address = 62.103.3.155 Acct-Status-Type = Start
(very big Acct-Session-Id will cause oracle error (ORA-01401: inserted value too large for column)
Environment: Solaris 8, gcc 2.95.3, Oracle 8.1.7
Attached are the outputs of gdb <executable> <core> with the bt and also output of truss
Kostas
-- Kostas Zorbadelos Systems Developer, Otenet SA mailto: [EMAIL PROTECTED]
Out there in the darkness, out there in the night out there in the starlight, one soul burns brighter than a thousand suns.
--------------------------------------- Television... a medium. So called because it is neither rare nor well-done. --------------------------------------- Ing. Andrea Gabellini Email: [EMAIL PROTECTED] Tel: 0549 886111 (Italy) Tel. +378 0549 886111 (International)
Intelcom San Marino S.p.A. Strada degli Angariari, 3 47891 Rovereta Repubblic of San Marino
http://www.omniway.sm http://www.intelcom.sm
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html