<div dir="ltr">Hi Colin,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 23, 2013 at 9:14 PM, Colin Mason <span dir="ltr"><<a href="mailto:cmason@frontiernetworks.ca" target="_blank">cmason@frontiernetworks.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I had stability issues with unixODBC-2.2.14-12 on CentOS 6. Adding Threading = 0 to my /etc/odbcinst.ini fixed the issues I was having.</span></p>
</div></blockquote><div><br></div><div style>Thanks a lot for the hint!</div><div style><br></div><div style>We haven't tried this yet but it sounds promising after reading <a href="http://wiki.freeswitch.org/wiki/Using_ODBC_in_the_core#.2Fetc.2Fodbcinst.ini_for_MySQL">http://wiki.freeswitch.org/wiki/Using_ODBC_in_the_core#.2Fetc.2Fodbcinst.ini_for_MySQL</a></div>
<div style>"<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.046875px">Also note, (see bug below on bottom of page); If you are using the FreeSWITCH pooled resources, then you definitely need Threading = 0 for high call volume. What this does is it "disables a global mutex in the ODBC core that only allows 1 concurrent operation per process regardless of the concurrent connections." (i.e. It slows down when you have too many connections trying at one time)"</span></div>
<div style><br></div><div style>Let's see if this actually helps. It could be that Threading=0 is default in unixODBC version 2.3 and that is why changing to that version resolved that issue.</div><div style><br></div>
<div style><br></div><div style>Br</div><div style>Julian</div></div></div></div>