[Home]

Summary:ASTERISK-03999: [patch] CDR_ODBC doesnt close the connection afther recording CDR.
Reporter:Alberto Fernandez (derkommissar)Labels:
Date Opened:2005-04-27 11:41:25Date Closed:2011-06-07 14:10:10
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/cdr_odbc
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cdr_odbc.c.diff
Description:CDR_ODBC is not closing the connection afther it has writen the cdr, leaving sessions opend on the MS SQL server. I have made a patch fixing this problem.
Comments:By: Olle Johansson (oej) 2005-04-27 11:47:51

Is this patch disclaimed (read the bug guidelines!) ?
By: Kevin P. Fleming (kpfleming) 2005-04-27 12:31:08

That module is intentionally leaving the connection open, so that it won't be hammering on the DB server with opens/closes. That's what the global 'connected' variable in the module is for.

If you are seeing multiple connections being opened even though 'connected' is non-zero, that's a different problem entirely. I won't put in this patch as it stands, since it would drastically impact performance for existing users.
By: Brian West (bkw918) 2005-04-27 13:17:28

I must agree with kevin on this.. I wrote it like this.. their is no reason to close the connection.  

/b
By: Alberto Fernandez (derkommissar) 2005-04-27 14:24:01

It has been leaving the connection open so far, now im not an expert pro. Im also not an expert in c, im just trying to put in my 2 cents, so here it is....

i see that for every cdr, it opens up a new connection, its even commented in the source.

 /* We really should only have to do this once.  But for some
          strange reason if I don't it blows holes in memory like
          like a shotgun.  So we just do this so its safe. */
                                                                                                             
       ODBC_res = SQLPrepare(ODBC_stmt, sqlcmd, SQL_NTS);
                                                                                                             
       if ((ODBC_res != SQL_SUCCESS) && (ODBC_res != SQL_SUCCESS_WITH_INFO)) {
               if (option_verbose > 10)
                       ast_verbose( VERBOSE_PREFIX_4 "cdr_odbc: Error in PREPARE %d\n", ODBC_res);
               SQLGetDiagRec(SQL_HANDLE_DBC, ODBC_con, 1, ODBC_stat, &ODBC_err, ODBC_msg, 100, &ODBC_mlen);
               SQLFreeHandle(SQL_HANDLE_STMT, ODBC_stmt);
               connected = 0;
               ast_mutex_unlock(&odbc_lock);
               return 0;
       }
By: Kevin P. Fleming (kpfleming) 2005-04-27 14:47:53

No, that is not correct. SQLPrepare does not open a connection, it 'compiles' an SQL statement for later processing.
By: Alberto Fernandez (derkommissar) 2005-04-27 16:29:44

All i know is that It has been leaving the connection opend, sometimes i had 500+ connections on the SQL server, doing nothing and the last stament was select 1 where 0=1 i added those lines afther playing around with the code, and its closing them now. Please help me understand why, and i apologize for opening this bug, i just want to return back to the astrisk community any advances i make, like i sayd im not an expert, but i get by.
By: Brian West (bkw918) 2005-04-27 17:48:39

the reason I tried to cache the prepare was because tclark said it was possible... then again it might be but taking to Nick on the unixODBC project said its not.  When i tried to cache the Prepare it would grab random things from memory and stuff into the sql query and stuff it into the database... you would end up with bits of sip debug... random memory and binary trash.  It was quite fun... hence my comment saying it blew a hole in memory like  shot gun.  Which it did  :P  

The prepare does things like escaping the naughty strings in each field.  I suspect that you have other issues.

/b
By: Kevin P. Fleming (kpfleming) 2005-04-28 11:33:48

Yes, I agree, the source of your problem lies somewhere outside of Asterisk. Please try to get on IRC with someone who can help you, or post a request for help to the asterisk-users list.