Kia ora, As many of you are aware (and for those who aren't) as part of Asterisk 13.8 changes went into the res_odbc module to more heavily leverage UnixODBC connection management and pooling capabilities. Previously we would use only a single connection to the database. Since this has been released many individuals have reported crashes and apparent deadlocks as a result of this change. We've been investigating and have some information we'd like to share so everyone can be aware of where things stand and where we can use some help.
These overall crashes have been a result of issues within both the database connectors themselves and UnixODBC. For database connectors old versions seem to have issues with unicode support within UnixODBC and with the threading constraints now placed upon them by using multiple connections heavily. Using the latest versions has resolved these specific crashes for people. For the UnixODBC crash the problem occurs at disconnect due to inadequate thread protection around critical environment data. This was fixed as of UnixODBC 2.3.2. Unfortunately distros may be shipping old versions causing the problem to be present for many individuals. The apparent deadlock appears to be due to a regression introduced in UnixODBC 2.3.3 in configuration caching. This has resulted in the cache not being used and also in the cache growing out of control. For each connection request the configuration is cached again in a linked list. As the number of connections grow this list grows longer and longer taking longer to iterate. While the cache has a 20 second expiration at heavy connection use it's still not enough to combat the growth. This issue has been reported upstream[1] and is on its way to being fixed in UnixODBC itself. To help confirm some of these we'd like people to try (if your environment allows you) a combination of UnixODBC 2.3.2 and the latest version of their database connector. This will allow us to confirm some of the above information in more environments and to see if any other issues may occur. Thank you for your help! Cheers, [1] http://mailman.unixodbc.org/pipermail/unixodbc-dev/2016-June/001890.html -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
