[asterisk-bugs] [JIRA] (ASTERISK-26601) app_voicemail: task_processor backed up

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234619#comment-234619 ] 

Richard Mudgett commented on ASTERISK-26601:
--------------------------------------------

{quote}
I would like to add that every time asterisk starts I get the following warning about the voicemail:
taskprocessor.c: The 'app_voicemail' task processor queue reached 500 scheduled tasks.
What is asterisk checking about voicemail that demand so much processing at startup?
{quote}
I haven't looked at the app_voicemail code but I would think asterisk is getting MWI for your 1000 mailboxes at startup so I can see why there could be 1000 tasks queued to the task processor.  The fact that you have 1000 mailboxes and the message happens at startup are useful pieces of information.

When any task processor queue reaches its high water limit it causes pjsip to stop accepting any _new_ requests (by ignoring/discarding them) until the queue works off the backlog.  Requests from current calls/dialogs should continue to be accepted in this state.  Once the backlog is worked off enough to reach the low water limit then pjsip will accept new requests again.  In other words this is a transient condition.  It should also be a short lived condition so retransmitted packets would then get processed.

The task processor reached X scheduled tasks message is logged _only_ once per task processor.  In your task processor list attachments, the app_voicemail task processor is the only one that has hit its high water limit and there is a relatively small or no backlog in any of the other queues.  Since you say you get the message at start up for app_voicemail this cause may actually be a red herring.  There is currently no way to tell if app_voicemail hits the high water limit again so we cannot rule out any _other_ causes of pjsip not working later.

So when your issue happens, is it transient or does it persist until you intervene?
Could something like fail2ban and iptables be blocking packets?
Are you using UDP, TCP, or TLS for your SIP transport?

> app_voicemail: task_processor backed up
> ---------------------------------------
>
>                 Key: ASTERISK-26601
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26601
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_voicemail, Resources/res_pjsip
>    Affects Versions: 14.1.1
>         Environment: Asterisk Realtime 14.1.0 rc1
>  PJSIP Driver
> mysql Ver 14.14
> pjproject 2.5.5
> spandsp 0.0.6
> jansson 2.7
> CentOS 6.6 64 bits on Vmware
> Number of phones : 700
> Average concurrent calls: 16
>            Reporter: Carl Fortin
>            Assignee: Unassigned
>         Attachments: backtrace-threads.txt, core-show-locks.txt, Debug_Asterisk_Backtrace.sh, Debug_log.txt, extconfig.conf, full, res_odbc.conf, sorcery.conf, task_procesor.txt, Task_processors_list2.txt, Task_processors_list.txt, voicemail.conf, voicemail_messages.sql, voicemail_users.sql
>
>
> I had Asterisk 14.1.0-rc1  running for 3 weeks, and all of the sudden PJSIP stopped working. Nothing in the console.
> I had time to save the task_processor output before restarting asterisk.
> After doing a restart to get the system back on I can see this in the log files:
> taskprocessor.c: The 'app_voicemail' task processor queue reached 500 scheduled tasks.
> I did not find any message concerning taskprocessor before the system stopped functioning.
> I'm aware that I am running an RC release, but looking at the release note, there were nothing concerning deadlock so I was thinking updating later.
>  



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