[asterisk-bugs] [JIRA] (ASTERISK-26914) Asterisk freezes for a few seconds under certain queue scenarios

[Rusty Newton (JIRA)]

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

Rusty Newton closed ASTERISK-26914.
-----------------------------------

    Resolution: Not A Bug

Thanks for following up and letting us know! I'll close it out.

> Asterisk freezes for a few seconds under certain queue scenarios
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-26914
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26914
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 13.14.0
>         Environment: CentOS 5, 16GB of memory, 4 core CPU never gets high usage.
> I use mysql_cdr module
>            Reporter: Michael Gaudette
>            Severity: Critical
>
> The way CDRs are recorded seem to create a problem when too many entries are associated to a channel. While it might be a generalized issue touching many modules, I am only aware of a way to reproduce it using queues.
> When the number of CDRs to be written (but not yet written to the DB - I use mysql_cdr) on a channel exceeds a specific number (it seems to be 5000 according to the error message) Asterisk won't take any SIP registrations and the SIP module (among possibly others) start acting up. It clears itself up within a minute or two.
> This scenario is easy to reproduce on my side: a queue, with ringall algorithm, 20 phones, all busy (on Do Not Disturb for example), 1 second between Ring attempts.  After about 250 seconds (5000 divided by 20) seconds of waiting what I described happens.
> I get this in the console:
> “taskprocessor_push: The 'subm:cdr_engine-00000003' task processor queue reached 5000 scheduled tasks again.”
> and at exactly the same time, a bunch of:
> "chan_sip.c: Autodestruct on dialog '1aec44fd134ae7b905e73cee1b14ab3e at 23.23.23.23:5060' with owner SIP/MYPBX-00001d94 in place (Method: BYE). Rescheduling destruction for 10000 ms"
> This seems to be because while multiple CDR`s are written per queue call, it`s only done at the  end of the call, so CDRs accumulate in memory/cacher/whatever and break some arbitrary limit. In truth, even if there was no Asterisk arbitrary limit the fact that CDRs are not flushed would eventually overwhelmed system resources I imagine, so just upping the limit would not be a great fix.
> This is happening on an Asterisk 11 server that was upgraded to Asterisk 13. It did not happen on 11, but then again I am aware CDRs were drastically overhauled start Asterisk 12, specifically with multiple CDR per queue calls..



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