[asterisk-bugs] [JIRA] (ASTERISK-19799) Apparent deadlock between ODBC Queue log and ODBC CDR

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-19799:
-----------------------------------

    Assignee: anonymouz666
      Status: Waiting for Feedback  (was: Open)

Have you experienced this problem under a recent supported version of Asterisk? There's been quite a lot of changes to all of these modules involved, including from a locking perspective.

> Apparent deadlock between ODBC Queue log and ODBC CDR
> -----------------------------------------------------
>
>                 Key: ASTERISK-19799
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19799
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue, CDR/cdr_odbc
>    Affects Versions: 1.8.11.0
>         Environment: CentOS 5.5 - 64-bit
>            Reporter: anonymouz666
>            Assignee: anonymouz666
>         Attachments: backends-output.txt, backtrace-iax2-deadlock-26-04-2012.txt, cdr_adaptive_odbc.txt, cdr.txt, CLI-output.txt, core-show-channels-26-04-2012.txt, extconfig.txt, iax2-show-channels-26-04-2012.txt, queue.txt, res_odbc.txt, sip-show-channels-26-04-2012.txt
>
>
> The scenario is just simple but with a high demand (about 200 active calls).
> The call arrives in Queue(). App_queue calls a Local channel to check if a member is local registered, if so, then Dial(SIP/agent). If is remote registered, then call through IAX2 to another box (Dial((IAX2/user:topsecret at 10.10.10.70/agent)).
> Occasionally, we have seen this machine deadlocking.
> Looking at the CLI logs, this time the issue happened in this order:
> The local members (SIP) started to print this message:
> [Apr 26 08:34:12] VERBOSE[5062] pbx.c:     -- Executing [7306 at MemberConnector:5] ExecIf("Local/7306 at MemberConnector-34c9;2", "1?Dial(SIP/7306)") in new stack
> [Apr 26 08:34:12] NOTICE[5062] chan_sip.c: Call to peer '7306' rejected due to usage limit of 1
> [Apr 26 08:34:12] VERBOSE[5062] app_dial.c:     -- Couldn't call SIP/7306
> [Apr 26 08:34:12] VERBOSE[5062] app_dial.c:   == Everyone is busy/congested at this time (0:0/0/0)
> We use call-limit=1 in all peers, but as soon as the sip channels got stuck (listed in sip show channels) the app_queue was not able to delivery calls anymore to devices that is still "active".
> We saw a lot of stuck channels using the command "sip show channels".
> And then after running more with the problem above, the IAX2 members (remote) started to print this message:
>  ExecIf("Local/7424 at MemberConnector-f367;2", "1?Dial(IAX2/user:topsecret at 10.10.10.70/7424,,tTwW)") in new stack
> [Apr 26 10:53:13] ERROR[2407]: chan_iax2.c:2384 peercnt_add: maxcallnumber limit of 2048 for 10.10.10.70 has been reached!
> [Apr 26 10:53:13] WARNING[2407]: chan_iax2.c:12127 iax2_request: Unable to create call
> [Apr 26 10:53:13] WARNING[2407]: app_dial.c:2218 dial_exec_full: Unable to create channel of type 'IAX2' (cause 34 - Circuit/channel congestion)
> And lots of IAX2 channels stuck in "iax2 show channels" - that's why the limit of 2048 was reached.
> After that, the app_queue completely stopped delivering calls.
> Attached there is a backtrace (can't run in debug_threads mode), core show channels, sip show channels and iax2 show channels.



--
This message was sent by Atlassian JIRA
(v6.2#6252)