Summary:	ASTERISK-13905: [patch] Asterisk cannot process calls if it cannot reach the voicemail database
Reporter:	Mike Oliveras (moliveras)	Labels:
Date Opened:	2009-04-06 16:12:01	Date Closed:	2011-06-07 14:02:51
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail/ODBC
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20090408__bug14838.diff.txt ( 1) odbc.ini ( 2) odbcinst.ini ( 3) res_odbc.conf ( 4) thread_apply_all_bt.txt ( 5) thread-apply-all-bt-5-6-09_2.txt ( 6) thread-apply-all-bt-5-6-09.txt
Description:	I am using asterisk 1.4.24 built with ODBC voicemail. If network connectivity is lost between asterisk and the voicemail database, asterisk cannot process calls.  It seems that while asterisk is trying to establish the tcp connection to the DB is it blocking. Can this be changed?
Comments:	By: Tilghman Lesher (tilghman) 2009-04-07 08:47:41 The only call that would be blocked is the call which is trying to access voicemail.  Asterisk is multi-threaded.  The only reason I'd see that you might block multiple calls is if you depend upon that same ODBC connection for something like Realtime database access. By: Mike Oliveras (moliveras) 2009-04-07 09:01:21 When I stop the database, I can no longer place any calls, I am not trying to call voicemail. Maybe because the extensions are constantly checking for MWI status?  We also have a script that sends SIP options to asterisk over the loopback interface, and will restart asterisk if it does not get a response after x number of retries.. when we loose connectivity to the DB the SIP options also do not get responded to. I can provide any additional info - just let me know. By: Tilghman Lesher (tilghman) 2009-04-07 10:22:53 Yes, MWI would also block. By: Mike Oliveras (moliveras) 2009-04-07 12:24:50 Are you still awaiting feedback from me? By: Tilghman Lesher (tilghman) 2009-04-08 11:35:48 This is a patch that enables negative connection caching and configurable connection timeouts.  This was derived from a developer branch, but it should work for this, as well.  You'll need to additionally set the connect_timeout and negative_connection_cache for this to have an effect.  If you're using MySQL as your backend, the values 1 and 300, respectively, should work fine. By: Mike Oliveras (moliveras) 2009-04-08 16:18:10 I built 1.4.24 with the attached patch, however the behavior was the same.  I am not using MySQL; I am using postgres-8.1.11 as my DB.  I am attaching my res_odbc.conf file as well as my odbc.ini and odncinst.ini files.  Thanks for looking at this. By: Tilghman Lesher (tilghman) 2009-04-09 10:02:39 For most cases, those values should have worked fine for Postgres, too. By: Tilghman Lesher (tilghman) 2009-05-04 18:01:19 Could you attach to the process with gdb while it's locked up and obtain a 'thread apply all bt', please? By: Mike Oliveras (moliveras) 2009-05-05 15:35:21 I am attaching it now. Thanks By: Tilghman Lesher (tilghman) 2009-05-05 16:33:31 What version of Postgres libraries are you running this with? By: Mike Oliveras (moliveras) 2009-05-05 16:38:53 These are the rpms that I am using.  I am running on CentOS 5.1 postgresql-libs-8.1.11-1.el5_1.1 postgresql-8.1.11-1.el5_1.1 postgresql-devel-8.1.11-1.el5_1.1 postgresql-odbc-08.01.0200-3.1 By: Tilghman Lesher (tilghman) 2009-05-05 16:41:29 I have a suspicion that this is a bug in PostgreSQL, but I'd need to look at the right body of source to know for sure. By: Tilghman Lesher (tilghman) 2009-05-05 17:13:27 Unfortunately, I cannot even look at the 8.1.11 source, as it has been removed from the PostgreSQL website and is no longer supported by them.  I would recommend that you upgrade to the latest 8.1 release (8.1.17), if you want to continue to use that series or upgrade to the latest 8.3 release (8.3.7) otherwise.  It appears to be a bug in that version, which is likely fixed in a later version, given that the backtrace given does not match even 8.1.15 source. By: Mike Oliveras (moliveras) 2009-05-06 13:33:30 I upgraded my postgresql server to 8.1.17; the behavior is the same. I will attach the thread apply all bt" output. By: Tilghman Lesher (tilghman) 2009-05-06 16:44:01 You may have, but the backtrace is still the same.  Are you sure you don't have multiple versions installed at the same time? By: Mike Oliveras (moliveras) 2009-05-06 18:54:23 I had upgraded my postgresql db, which is running on another machine. I just tried upgrading the postgresql packages on the asterisk machine to the following.   postgresql-libs-8.1.17-1PGDG.rhel5 postgresql-devel-8.1.17-1PGDG.rhel5 postgresql-odbc-08.01.0200-3.1 postgresql-8.1.17-1PGDG.rhel5 I will attach the backtrace for this one. By: Mike Oliveras (moliveras) 2009-05-13 13:45:27 Do you need any additional info from me? By: Tilghman Lesher (tilghman) 2009-05-18 12:11:14 This definitely looks like a Postgres bug.  It's waiting too long for a connect, despite the fact that UnixODBC has a 10 second connection timeout. By: Mike Oliveras (moliveras) 2009-05-18 16:38:54 I am using the postgresql-odbc driver rather than the one that comes with the unixODBC; I was getting crashes with that one.  Would you recommend trying to upgrade my postgresql-odbc driver? [root@mikeo_asterisk1 ~]# cat /etc/odbcinst.ini # Included in the unixODBC package [PostgreSQL] Description     = ODBC for PostgreSQL #Driver         = /usr/lib/libodbcpsql.so --> from unixODBC Driver          = /usr/lib/psqlodbc.so  --> from postgresql-odbc #Setup          = /usr/lib/libodbcpsqlS.so FileUsage       = 1 By: Tilghman Lesher (tilghman) 2009-05-18 17:23:29 At this point, I would recommend opening a bug report with the Postgres ODBC project.