I tested this issue with version 13 and version 18. In res_odbc.conf, if I add a second, new data source like [asterisk] enabled=yes dsn=asterisk sanitysql => select 1 isolation => read_committed username=root ;password pre-connect => yes forcecommit => yes connect_timeout => 10 negative_connection_cache => 0 max_connections =>500 my odbc.ini [cdr] Description = MySQL ODBC Driver Testing Driver = maria Socket = /var/run/mysqld/mysqld.sock User = root Password Database = public Option = 3 I get, immediately, segmentation fault. With only one, it works fine. Is this by design? Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230816/51ab4173/attachment.html>
You should be able to define multiple data sources. However I'm having my own issues. I have my dialplan accessing one maria database which is hosted locally on the asterisk server then logging cdr with odbc adaptive which connects to maria on a remote machine. This works fine except when the remote server is out of reach the calls zombie and eventually lead to a fault. The cli imply that the calls hang on SET(CDR_PROP(disable)=1) which is ironic since instructing the system not to connect to the cdr server appears to cause the problem and there may be a defect in the adaptive_odbc implementation where it somehow still communicates with the server during the cdr_func(disable). My experimentation suggests that the maria_odbc driver utilizes a single thread (there are odbc directives to adjust this - but it seems they have been superseded). Once a cdr hangs, new calls hang on odbc calls to the local database. In my case the remote server is 5' away and in the same switch that Asterisk is plugged into, so it hasn't been critical to fix this - but it may provide some clues to your situation. On Thu, Aug 17, 2023 at 11:04 AM Federico <federico at digitalipvoice.com> wrote:> I tested this issue with version 13 and version 18. > > In res_odbc.conf, if I add a second, new data source like > > > > [asterisk] > > enabled=yes > > dsn=asterisk > > sanitysql => select 1 > > isolation => read_committed > > username=root > > ;password> > pre-connect => yes > > forcecommit => yes > > connect_timeout => 10 > > negative_connection_cache => 0 > > max_connections =>500 > > > > my odbc.ini > > [cdr] > > Description = MySQL ODBC Driver Testing > > Driver = maria > > Socket = /var/run/mysqld/mysqld.sock > > User = root > > Password > > Database = public > > Option = 3 > > > > > > I get, immediately, segmentation fault. > > With only one, it works fine. > > Is this by design? > > > > Philip > > > > > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230817/8062d56f/attachment.html>
On Wed, Aug 16, 2023 at 7:48 PM Federico <federico at digitalipvoice.com> wrote:> I tested this issue with version 13 and version 18. > > In res_odbc.conf, if I add a second, new data source like > > > > [asterisk] > > enabled=yes > > dsn=asterisk > > sanitysql => select 1 > > isolation => read_committed > > username=root > > ;password> > pre-connect => yes > > forcecommit => yes > > connect_timeout => 10 > > negative_connection_cache => 0 > > max_connections =>500 > > > > my odbc.ini > > [cdr] > > Description = MySQL ODBC Driver Testing > > Driver = maria > > Socket = /var/run/mysqld/mysqld.sock > > User = root > > Password > > Database = public > > Option = 3 > > > > > > I get, immediately, segmentation fault. > > With only one, it works fine. > > Is this by design? >There's nothing explicitly written to prevent such a thing within Asterisk itself. There is no backtrace here so nothing to show where the crash actually occurred, be it Asterisk itself or UnixODBC. If UnixODBC we're a somewhat simple user of it, so specific configuration of it or its build may be the source of it. -- Joshua C. Colp Asterisk Project Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230818/35587fed/attachment.html>
Hi Federico, Segfaults are 100% not by design. Typically if something seg faulted, either there is a logic bug or a component mismatch. The you should definitely be able to use more than one connection (we use multiple connections with postgres odbc with no issue). If Asterisk segfaults when using odbc Try this: - use ps and get the pid of Asterisk - run gdb, attach to the asterisk pid - do something that would cause the seg fault - get a backtrace (bt) and show all threads backtrace (thread apply all bt) if Asterisk segfaults when starting up Run Asterisk straight from gdb Wait for segfault, get backtrace, and all threads backtrace On 8/16/23 18:48, Federico wrote:> > I tested this issue with version 13 and version 18. > > In res_odbc.conf, if I add a second, new data source like > > [asterisk] > > enabled=yes > > dsn=asterisk > > sanitysql => select 1 > > isolation => read_committed > > username=root > > ;password> > pre-connect => yes > > forcecommit => yes > > connect_timeout => 10 > > negative_connection_cache => 0 > > max_connections =>500 > > my odbc.ini > > [cdr] > > Description = MySQL ODBC Driver Testing > > Driver = maria > > Socket = /var/run/mysqld/mysqld.sock > > User = root > > Password > > Database = public > > Option = 3 > > I get, immediately, segmentation fault. > > With only one, it works fine. > > Is this by design? > > Philip > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230819/04197393/attachment.html>