[asterisk-bugs] [JIRA] (ASTERISK-27985) PJSIP: Does not respond to INVITES when any taskprocessor queue length is > high water level

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-27985:
--------------------------------------------

Allowing fine tuning adjustments to stasis taskprocessors starts getting into the realm of the absurd in configurability.  If you are able to tweak the levels you also have to consider how long the system may need to work off the excess tasks in the queue to get back to normal operation.  If you subsequently upgrade to a new version you may have to re-tweak the levels.  Also taskprocessors can come and go from release to release.  There are internal routines available to set the levels on taskprocessors.  Only select taskprocessors tend to need their levels adjusted from the default 450/500 levels.  As you can see in the CLI "core show taskprocessors" output a few of them do have their levels adjusted by the code to higher levels.

A couple patches were submitted by the community to adjust some taskprocessor levels by configuration.  The app_voicemail taskprocessor is set by the tps_queue_high and tps_queue_low options in voicemail.conf.  The pjsip/mwi taskprocessor levels are set by mwi_tps_queue_high and mwi_tps_queue_low in pjsip.conf.  (I'm not sure if the submitter would still need to tweak the pjsip/mwi levels after ASTERISK-26806 came out in a release.)  None of the other taskprocessor levels are currently user configurable.

As far as the speed of the machine vs the hard-coded queue levels are concerned.  I think the levels would be nearly the same among various machines anyway.  A faster machine can put more tasks into the queue but it can also clear the queue faster.  I think a more likely reason there could be different levels needed between installations is the what the installation is used for.  (Different calling patterns, applications, etc.)

As far as notifying the user, there is no "crit" or "emerg" log level defined.  There is the WARNING message when a taskprocessor hits the high water trigger level.  There is a DEBUG level 3 message when a taskprocessor drops to the low water trigger level after hitting the high water trigger.  There is no message when all taskprocessors have dropped below the low water trigger levels.  As far as missing the notification is concerned that's what scripts grepping the logs do best.

At any rate, patches welcome. :)

> PJSIP: Does not respond to INVITES when any taskprocessor queue length is > high water level
> --------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27985
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27985
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CEL/cel_odbc
>    Affects Versions: 15.4.1, 13.22.0
>         Environment: FreePBX 14, SNG7
>            Reporter: xrobau
>              Labels: pjsip
>         Attachments: pjsip-ignored.txt
>
>
> We've had sporadic reports of AGIs causing audio glitches on heavy systems (which we believe is related to ASTERISK-26257 but is NOT limited to confbridge, MOH and Playback/Background is also affected).
> {code}
> exten => 998,1,Answer
>  same => n,Dial(Local/999 at from-internal-custom/n,300,gm(default))
>  same => n,Playback(beep)
>  same => n,Goto(1)
> exten => 999,1,Set(COUNT=0)
>  same => n(loop),GotoIf($[ ${COUNT} > 1000 ]?toomany)
>  same => n,Gosub(testtrigger)
>  same => n,Set(COUNT=$[ ${COUNT} + 1 ])
>  same => n,Goto(loop)
>  same => n(toomany),Hangup
>  same => n(testtrigger),Dial(SIP/8675309 at 127.0.0.1:5160,1,g)
>  same => n,Return
> {code}
> The above dialplan simulates a call entering the 'from-pstn' context of FreePBX, which then does - after the standard dialplan - a Hangup. 
> This causes Asterisk to create about 20-30 calls per second (but does not trigger the audio issue, unfortunately).  It does however trigger a new issue where PJSIP channel INVITES are ignored until the cel_aggregation_topic queue is empty:
> {code}
> Processor                                      Processed   In Queue  Max Depth  Low water High water
> ... skipped lines ...
> subm:cdr_engine-00000003                         5780891          0       2347       4500       5000
> subm:cel_aggregation_topic-00000006              4968215     786689    2961396       2700       3000
> subm:endpoint_topic_all-cached-00000008              794          0         13        450        500
> subm:endpoint_topic_all-cached-0000005a              778          0         13        450        500
> subm:manager_topic-00000007                      5962603          0        344       2700       3000
> {code}
> While the queue is being processed, pjsip calls are ignored.  chan_sip calls are answered and processed correctly, increasing the queue size.



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