Asterisk Version: 13.9.1 OS/Distro: Fedora Server 23
unixODBC: 2.3.4 (Fedora Package Manager) Threading: 0 Pooling: yes ODBC Connector: 5.3.6 (MySQL Fedora Repository) [ANSI or Unicode] Status: No Crash, but unixODBC locks ________________________________ From: [email protected] <[email protected]> on behalf of Marek Červenka <[email protected]> Sent: 01 June 2016 11:24 To: [email protected] Subject: Re: [asterisk-dev] URGENT - PJSIP Sorcery Locking will be helpfull comparison table like this? http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC Asterisk Realtime ODBC - voip-info.org<http://www.voip-info.org/wiki/view/Asterisk+Realtime+ODBC> www.voip-info.org asterisk version OS/Distro unixODBC threading pooling odbc-connector SQL server status 13.9.1 Linux/Centos 6 2.3.2 (backport fc20) 0 yes 5.1.5 distro MySQL 5.1.73 distro random segfaults 13.9.1 Linux/Centos 6 2.3.4 (backport fc23)0 yes 5.3.6 Dne 1.6.2016 v 7:04 Matt Fredrickson napsal(a): Hey Ross, At this time, we’re not thinking about reverting the ODBC change, although we are actually working on an issue internally related to that particular change. If it looks like that there is an underlying systemic issue that we are unable to resolve in a timely manner, it’s quite possible that the change could be backed out. So in essence, my thoughts are twofold: 1. Keep moving forward with ODBC changes - but make sure that we’ve got testing in place to prove functionality. 2. If it all goes down and we’re playing whack a mole with ODBC bugs, revert the changes until we can do some better testing. Certified Asterisk goes through its own testing and vetting process and changes in the branch are driven almost exclusively by certified customers. Right now, the 13.8 certified branch is going through the initial testing process. There is at least one open issue that we’ve found so far related to the ODBC change that may or may not be related to your crash, which is being worked on by a member of the Asterisk development team at Digium. Additionally, and completely separate from the certified testing and release process, a deadlock in the ODBC code is highly concerning, and if it looks like there are systemic issues related to the performance improvement added, we will almost certainly look into those as well. I might add that although Digium as a commercial entity is a large contributor to the Asterisk project, the goal is for it to also be a community project. With that perspective, we also encourage community members to find ways to contribute as well, whether it be via Digium’s products and services, or helping by employing others that can contribute to the project. We desire and welcome any and all positive participation. Thanks *so* much again for the valuable feedback. Like I said, hopefully we’ll be able to get a few of these hickups addressed soon. Best wishes, Matthew Fredrickson On Tue, May 31, 2016 at 11:01 AM, Ross Beer <[email protected]><mailto:[email protected]> wrote: Hi All, I've been looking into the changes made to res_odbc and the removal of connection handling. I can see that this change has been murged into the next release of Certified Asterisk. Would it be possible to regress this change until a sutible solution to the locking is found? Kind regards, Ross On Mon, May 30, 2016 at 8:43 AM -0700, "Joshua Colp" <[email protected]><mailto:[email protected]> wrote: Ross Beer wrote: Hi, I'm having an issue with the latest asterisk verison 13.9.1 and SVN MASTER: <snip> There are currently around 9 locks held and no phones are able to register. The system is using the latest unixODBC and mysql-connector-odbc drivers. This has been working well up until recently. However a change appears to have been made to the way endpoints are authenticated. I'm exploring the possibility that this may be a unixODBC issue however I would be great full if anyone could offer any assistance? A full backtrace[1] would be needed to see what is going on. You should also file an issue and link it here. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com<http://www.digium.com> & www.asterisk.org<http://www.asterisk.org> -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- --------------------------------------- Marek Cervenka =======================================
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
