[asterisk-bugs] [Asterisk 0012704]: ODBC connections are not being pooled or reused.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12704 
====================================================================== 
Reported By:                falves11
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   12704
Category:                   Resources/res_odbc
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 117297 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-21-2008 16:15 CDT
Last Modified:              05-21-2008 17:34 CDT
====================================================================== 
Summary:                    ODBC connections are not being pooled or reused.
Description: 
This is what I observe after using version 117297 in production: the number
of connections grow about 60 a day, but I have just a few calls open on the
server. If they were reused, the max amount of connections should not grow
to more tha maybe 20 or less, since I don't need to hit the database at the
same time. So there is a loose end here somewhere. The pool does not reuse
the connections properly or cannnot tell if they are idle. 
====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 05-21-08 17:34  
---------------------------------------------------------------------- 
The fact that they all show up as "connected" means that none of them are
in use, so you did, in fact, have a point in time at which 34 different
calls were in the process of posting their CDRs.  If this seems off to you,
you might want to look at the number of indices you have on your CDR table,
as a long INSERT time tends to indicate a lot of contention. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-21-08 17:34  Corydon76      Note Added: 0087185                          
======================================================================