[asterisk-dev] URGENT - PJSIP Sorcery Locking

Wed Jun 1 07:17:38 CDT 2016

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: asterisk-dev-bounces at lists.digium.com <asterisk-dev-bounces at lists.digium.com> on behalf of Marek Červenka <cervajs at fpf.slu.cz>
Sent: 01 June 2016 11:24
To: asterisk-dev at lists.digium.com
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 <ross.beer at outlook.com><mailto:ross.beer at outlook.com> 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" <jcolp at digium.com><mailto:jcolp at digium.com>
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
=======================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160601/b43bf4ab/attachment-0001.html>