[asterisk-bugs] [Asterisk 0011798]: [patch] Idle check for res_odbc

noreply at bugs.digium.com noreply at bugs.digium.com
Sun Jan 20 09:56:38 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11798 
====================================================================== 
Reported By:                Corydon76
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11798
Category:                   Resources/res_odbc
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 98978 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-19-2008 12:03 CST
Last Modified:              01-20-2008 09:56 CST
====================================================================== 
Summary:                    [patch] Idle check for res_odbc
Description: 
When a database connection remains idle for too long, it may sometimes
become stale.  This patch makes Asterisk more proactive in the approach, in
that we can set a max idle time, at which res_odbc will automatically
reconnect instead of waiting for a query to fail first.  This should
improve some performance, as well as eliminating ugly logs about the
database connection having timed out.
====================================================================== 

---------------------------------------------------------------------- 
 mvanbaak - 01-20-08 09:56  
---------------------------------------------------------------------- 
Asterisk has been idle all night and day, and I received a call just 10
minutes ago. I had the same yesterday and back then it coredumped. I'm now
running with this patch and no more coredump. This is the new log:

[2008-01-20 16:52:23] WARNING[6314]: res_odbc.c:535 odbc_obj_disconnect:
res_odbc: customer-a [customer-a] already disconnected
[2008-01-20 16:52:23] NOTICE[6314]: res_odbc.c:571 odbc_obj_connect:
Re-connecting customer-a
[2008-01-20 16:52:23] NOTICE[6314]: res_odbc.c:587 odbc_obj_connect:
res_odbc: Connected to customer-a [customer-a]
[2008-01-20 16:52:23] WARNING[6314]: res_odbc.c:121
ast_odbc_prepare_and_execute: SQL Execute returned an error -1: HYT00:
[MySQL][ODBC 3.51 Driver][mysqld-5.0.32-Debian_7etch4-log]MySQL server has
gone away (84)                                                             
                                                                           
                                                                      
[2008-01-20 16:52:23] WARNING[6314]: res_odbc.c:129
ast_odbc_prepare_and_execute: SQL Execute error -1! Attempting a
reconnect...
[2008-01-20 16:52:23] WARNING[6314]: res_odbc.c:221 ast_odbc_sanity_check:
Connection is down attempting to reconnect...
[2008-01-20 16:52:28] WARNING[6314]: res_odbc.c:533 odbc_obj_disconnect:
res_odbc: disconnected 0 from customer-b [customer-b]
[2008-01-20 16:52:28] NOTICE[6314]: res_odbc.c:573 odbc_obj_connect:
Connecting customer-b
[2008-01-20 16:52:28] NOTICE[6314]: res_odbc.c:587 odbc_obj_connect:
res_odbc: Connected to customer-b [customer-b]
  == Spawn extension (internal, sw-13-6002, 10) exited non-zero on
'Local/6002 at internal-d65d;2'
  == Spawn extension (from-provider, sw-14-31318XXXXXX, 20) exited
non-zero on 'IAX2/vanbaak-8'
    -- Hungup 'IAX2/vanbaak-8'
  == Spawn extension (internal, sw-13-6000, 10) exited non-zero on
'Local/6000 at internal-0d22;2'

So it really does fix the crash.
+1 from me for commit 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-20-08 09:56  mvanbaak       Note Added: 0080914                          
======================================================================




More information about the asterisk-bugs mailing list