On Wed, Jan 23, 2013 at 9:20 PM, Steven Ayre <steveayre@gmail.com> wrote:

Personally I'm using FS + unixODBC + myODBC for MySQL with no stability issues. It should be fine.
The issue occurs under higher loads or peaks, nothing you will notice in any small business or home environments.

UP 0 years, 126 days, 19 hours, 37 minutes, 42 seconds, 994 milliseconds, 957 microseconds

FreeSWITCH is ready

42124396 session(s) since startup

If you do get issues report them on the Debian BTS - I'm sure they'd get it fixed, either by an updated package or backporting a fix to the current version. Bugs only get fixed if they're reported to the correct place people!

Actually this is nearly what I did already, you should have read my first message more carefully.
It is about requesting more information about the issue if anybody has those, not about asking for support to resolve the issue. We know that this is caused by unixODBC already but not exactly at which point and why it helps to install an newer version.

I actually intended that about whoever added the note to the Wiki since the debian maintainer obviously hadn't heard from them. If the note on the Wiki is from you, apologies.

The maintainer of the Debian package asked me to provide more information so that he can understand the issue in detail to create a patch for the package in Wheezy.

If FS coredumps within unixODBC try:

http://wiki.freeswitch.org/wiki/Reporting_Bugs#Creating_A_Backtrace_With_gdb_.28Linux.2FUnix.29

If a simple program can be written that demonstrates the same instability, then even better since the backtrace then might be more readable. If it's only under high load then it could be thread related so you'd need to reproduce that.

In any case I don't think you'll find problems with myODBC, but obviously test before rolling into production.

As said, the issue is with unixODBC, not the myODBC connector which is a different thing.

I said myODBC since I haven't used unixODBC with any of the other connectors personally. Even if the crash appears to be in unixODBC it could still be in the connector used too since that code is called from unixODBC and could be some mismatch between what they're doing.

-Steve