| Summary: | ASTERISK-22708: res_odbc.conf negative_connection_cache option not respected, failover between DSNs doesn't work | ||
| Reporter: | JoshE (n8ideas) | Labels: | |
| Date Opened: | 2013-10-15 12:22:12 | Date Closed: | 2015-05-17 15:19:17 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Functions/func_odbc Resources/res_odbc |
| Versions: | SVN 11.5.1 11.7.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | CentOS 6 | Attachments: | ( 0) full ( 1) odbc_errors.txt |
| Description: | The database failover behavior does not work as expected with MySQL / MariaDB on the databases. Based on a reading of the documentation and source, I would expect this config in res_odbc to behave differently than it does:
[config] enabled => yes dsn => MySQL username => user password => hidden pre-connect => yes sanitysql => select 1 idlecheck => 30 share_connections => yes connect_timeout => 2 negative_connection_cache => 300 [config_2] enabled => yes dsn => MySQL-2 username => user password => hidden pre-connect => yes sanitysql => select 1 idlecheck => 30 share_connections => yes connect_timeout => 2 negative_connection_cache => 300 Based on my reading, a connect timeout getting hit should cause a negative cache where new connections are not attempted for 300 seconds. That does not occur in practice. The server continually attempts to reconnect to the server, meanwhile the entire system becomes totally unusable until the database connection is restored. | ||
| Comments: | By: JoshE (n8ideas) 2013-10-15 12:23:37.021-0500 CLI output attached. By: Rusty Newton (rnewton) 2013-10-31 09:41:13.816-0500 Can you provide another log, but including the DEBUG message type , with debug turned up to 5 "core set debug 5" or set in asterisk.conf? Get at least 20 or 30 lines around where the connection attempts are occurring. By: JoshE (n8ideas) 2013-11-03 23:50:07.548-0600 Here's a full debug on this, which shows the connection being attempted over and over again. At the same time, the server becomes mostly unresponsive. By: JoshE (n8ideas) 2013-11-03 23:50:34.455-0600 Debugging is now attached. Hopefully this helps. By: Rusty Newton (rnewton) 2013-11-14 18:40:38.079-0600 Thanks! That does help. Sounds like there are two problems here: 1. negative_connection_cache doesn't appear to work, or the documentation doesn't represent it's behavior correctly 2. func_odbc only appears to try connecting to your one DSN and not the second. Regarding 1, I may be misunderstanding how negative_connection_cache works, but it sounds like Asterisk shouldn't attempt a connection back to that same DSN again within the time frame specified. I went ahead and set up a test and found essentially what you saw. Despite the negative_connection_cache setting, any attempts to query the database were actually attempted and of course failed because I had created a disconnected scenario. Based on the sample file description of the negative_connection_cache and the description here: http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg48943.html I would have expected different behavior. Specifically, that I the database connections shouldn't have been attempted. Regarding 2, Can you attach your func_odbc.conf, or verify that you have specified the DSN's for both of your databases in the function configuration that you are using? By: JoshE (n8ideas) 2013-11-15 08:37:43.473-0600 Rusty- there are a couple areas where this is affected - func_odbc and also realtime peers. It basically all goes haywire when you force this situation. In an ideal world, the extconfig that lets you do: sippeers => odbc,config_1,sippeers,1 sippeers => odbc,config_2,sippeers,2 We have the same thing set up for func_odbc, where we have these DSNs ordered: [GEN_HINT] dsn=config_1,config_2 In practice, none of this works as expected. By: Marek Cervenka (cervajs) 2015-02-27 16:06:25.635-0600 +1 asterisk 11.16.0, unixODBC-2.3.2, mysql-connector-odbc-5.1.5r1144 By: Marian Piater (maikyp) 2015-03-01 12:06:56.910-0600 +1 Debian Wheezy, Asterisk 11.15.0, unixodbc 2.2.14p2-5, libmyodbc 5.1.10-2+deb7u1 By: Matt Jordan (mjordan) 2015-03-01 12:19:58.005-0600 Adding a +1 to an issue doesn't actually help, nor does it cause it to raise any in any priority. What actually *does* help is a patch. If you're interested in contributing a patch that fixes this issue, that would be extremely helpful. Instructions on how to contribute a patch back to the project can be found here: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process By: Rusty Newton (rnewton) 2015-03-02 11:46:20.712-0600 For those that can't provide a patch; note that bug bounties are allowed on the asterisk-dev mailing list. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties By: Marek Cervenka (cervajs) 2015-03-10 09:37:23.128-0500 nobody picked bounty http://lists.digium.com/pipermail/asterisk-dev/2015-March/073211.html is there way to get help from Digium? I purchased Asterisk Support but there isnt option to solve bugs by Digium folks By: Martin Tomec (matesstar) 2015-04-21 12:14:29.385-0500 I have submited a patch: https://gerrit.asterisk.org/#/c/182/ Hopefully it will be accepted. By: Rusty Newton (rnewton) 2015-05-17 15:19:17.183-0500 Closing this out. Looks like a fix was merged: https://gerrit.asterisk.org/#/c/182/ | ||