[asterisk-bugs] [JIRA] (ASTERISK-29340) stasis: PJSIP endpoint taskprocessor congestion after upgrading

[Jan Blom (JIRA)]

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

Jan Blom commented on ASTERISK-29340:
-------------------------------------

I still get the taskprocessor messages as well. The max depth of the taskprocessor is still above the limit.

>From the latest log file:

{noformat}
Processor                                                               Processed   In Queue  Max Depth  Low water High water
stasis/p:endpoint:PJSIP/proxy-00000019                                    1584102          0       1859        450        500
{noformat}

> stasis: PJSIP endpoint taskprocessor congestion after upgrading
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-29340
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29340
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Stasis, Resources/res_pjsip
>    Affects Versions: 18.2.2
>         Environment: 8 core vm, lots of RAM,
> CentOS Linux release 7.5, Asterisk 18.2.2
>            Reporter: Jan Blom
>            Assignee: Jan Blom
>         Attachments: modules 18.2.2.txt, stasis statistics 18.2.2.txt, taskprocessors 16.6.1.txt, taskprocessors 18.2.2.txt, taskprocessors decline ast_channel_varset_type.txt
>
>
> After upgrading from Asterisk 16.6.1 to 18.2.2 I notice a difference in how tasks are processed by the taskprocessors. 
> My setup is that the asterisk box receives inbound calls (using chan_pjsip) from a single endpoint (SIP proxy).
> There is one taskprocessor {{stasis/p:endpoint:PJSIP/<endpoint name>}} that handles a magnitude more messages than any other taskprocessor and the max depth is well above the high watermark. 
> Using the older Asterisk 16.6.1 and identical configuration, the same taskprocessor receives no messages. 
> This is the taksprocessor in question, after a testrun with 4170 calls at a rate of 100 calls per second.
> bq.stasis/p:endpoint:PJSIP/proxy-00000019                                    1579171          0       1597        450        500
> I have attached the complete list of taskprocessors (core show taskprocessors) after a testrun. For both Asterisk versions.
> The dialplan is quite simple, only answering, playing a prompt and hangup. It also involves a few ODBC database calls. However, changing the dialplan to just answer, wait a few seconds and hangup will result in the same behavior,. Even though the number of messages processed by the taskprocessor will decrease a bit, it will still be a huge number. 
> I am not entirely sure this is a problem. Calls seem to be handles properly and audio is fine. However, it is a big change in behavior compared with Asterisk 16 and a potential bottleneck if a single task is going to process a huge amount of messages. Except from this taskprocessor, all other message handling is well distributed over the various taskprocessors. 
> Another annoyance is that the log gets filled with these warnings:
> bq.taskprocessor.c:1160 taskprocessor_push: The 'stasis/p:endpoint:PJSIP/proxy-00000019' task processor queue reached 500 scheduled tasks again.
> Most bells and whistles are disabled, no ARI, AMI, AGI. SIP UDP only.
> The list of loaded modules in Asterisk 18.2.2 is attached.



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