[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 16:48 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. 
====================================================================== 

---------------------------------------------------------------------- 
 falves11 - 05-21-08 16:48  
---------------------------------------------------------------------- 
SQL Servers sees 43 connections

ODBC DSN Settings
-----------------

  Name:   global
  DSN:    mssql
  Pooled: Yes
  Limit:  1000
  Connections in use: 34
    - Connection 1: connected
    - Connection 2: connected
    - Connection 3: connected
    - Connection 4: connected
    - Connection 5: connected
    - Connection 6: connected
    - Connection 7: connected
    - Connection 8: connected
    - Connection 9: connected
    - Connection 10: connected
    - Connection 11: connected
    - Connection 12: connected
    - Connection 13: connected
    - Connection 14: connected
    - Connection 15: connected
    - Connection 16: connected
    - Connection 17: connected
    - Connection 18: connected
    - Connection 19: connected
    - Connection 20: connected
    - Connection 21: connected
    - Connection 22: connected
    - Connection 23: connected
    - Connection 24: connected
    - Connection 25: connected
    - Connection 26: connected
    - Connection 27: connected
    - Connection 28: connected
    - Connection 29: connected
    - Connection 30: connected
    - Connection 31: connected
    - Connection 32: connected
    - Connection 33: connected
    - Connection 34: connected

  Name:   routing
  DSN:    routing
  Pooled: Yes
  Limit:  1000
  Connections in use: 9
    - Connection 1: connected
    - Connection 2: connected
    - Connection 3: connected
    - Connection 4: connected
    - Connection 5: connected
    - Connection 6: connected
    - Connection 7: connected
    - Connection 8: connected
    - Connection 9: connected


Since I have a separate connection for routing, this means that cdr_odbc
is using 34 connections alone. I have 64 open calls. The routing
connections via func_odbc seem to be OK. Therefore, cdr_odbc is the
culprit. There is no way that with 64 calls open I could have so many
cdr_connections. And they keep growing. Tomorrow I can read the number
again. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-21-08 16:48  falves11       Note Added: 0087183                          
======================================================================