Summary:ASTERISK-13556: slow ODBC database completely LOCK chan_sip
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2009-10-21 11:30:58Date Closed:2011-06-07 14:08:26
Versions:Frequency of

Perform regular at "do_monitor" takes a bad
Connection to the voice mail to an ODBC database LOCK, while taking the
Asterisk SIP packets to any other. Provoke can do that with
increased duration to connect to the database, permission to load the
Database (import SQL dump)


>core show locks
=== Currently Held Locks ==============================================
=== <file> <line num> <function> <lock name> <lock addr> (times locked)
=== Thread ID: -1214764144 (do_monitor           started at [16923]
chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 16869 do_monitor &monlock
0xb7a19d80 (1)
=== ---> Lock #1 (chan_sip.c): MUTEX 16891 do_monitor &(peer)->_lock
0x823778c (1)
=== -------------------------------------------------------------------
=== Thread ID: -1270899824 (netconsole           started at [ 1036]
asterisk.c listener())
=== ---> Lock #0 (chan_sip.c): MUTEX 10654 _sip_show_peers
&(&peerl)->_lock 0xb7a1c0c0 (1)
=== ---> Waiting for Lock #1 (chan_sip.c): MUTEX 10654 _sip_show_peers
&(iterator)->_lock 0x823778c (1)
=== --- ---> Locked Here: chan_sip.c line 16891 (do_monitor)
=== ------------------------------------------------------------------
Comments:By: Leif Madsen (lmadsen) 2009-10-22 08:46:30

Based on the IRC discussion here, I believe this will only be resolved in and not fixable in 1.6.0 and 1.4.

<wildzero-cw> hello, when sip_send_mwi_to_peer in chan_sip (*1.4-svn) is called and i use odbc voicemail, and the odbc SELECT is slow (let's say 1000ms) then _entire_ chan_sip goes to sleep 1000ms, and the  Recv-Q gets crowded, also see issue 16110, that's dump

<file> same goes for realtime when querying the DB.

<kpfleming> wildzero-cw: you won't have that problem in and later, because SIP MWI no longer polls the database each time, it's event based

<kpfleming> it's not likely to be fixable in 1.4 and 1.6.0, without moving the MWI sending operations of chan_sip into their own thread

<kpfleming> and of course, an ODBC database that takes 1+ seconds to respond is going to cause problems all over the place