[asterisk-bugs] [JIRA] (ASTERISK-28424) Task processor queue regularly fills up with subscriptions, using curl config and external mwi, test phone doesn't stay registered

[Benjamin Keith Ford (JIRA)]

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

Benjamin Keith Ford updated ASTERISK-28424:
-------------------------------------------

    Assignee: David Moore
      Status: Waiting for Feedback  (was: Triage)

How many peers are you loading at a time? What's your process for loading via curl? From what you've said, I'm assuming the only thing being done on the system is the register and subscribe, correct?

> Task processor queue regularly fills up with subscriptions, using curl config and external mwi, test phone doesn't stay registered
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28424
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28424
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Subscriptions, Core/Sorcery, Core/Stasis, Resources/res_config_curl, Resources/res_mwi_external
>    Affects Versions: 13.26.0
>         Environment: Debian 9 virtualized on vmware
>            Reporter: David Moore
>            Assignee: David Moore
>         Attachments: extconfig.conf, fulllog_truncated, taskproc
>
>
> We are using external mwi with chan_sip and dbsep.cgi, loading sippeers through curl
> This is a testing system with a single phone registered (Mitel 6731i) and no calls happening. The only thing asterisk has to do is keep the phone registered
> Task processors seem to be overloaded, which causes the single test phone to become lagged and/or unreachable on a regular basis.
> We see the following log message occurring hundreds or thousands of times per second, in regular intervals-
> {quote}
> [May 22 10:04:11] DEBUG[4846] threadpool.c: Increasing threadpool stasis/pool's size by 0
> {quote}
> We also see the following, also in regular intervals-
> {quote}
> [May 22 10:05:48] DEBUG[25927] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[25928] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[25925] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[25930] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[25929] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[25931] threadpool.c: Worker thread idle timeout reached. Dying.
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12668
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12669
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12672
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12664
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12673
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12665
> [May 22 10:05:48] DEBUG[4846] threadpool.c: Destroying worker thread 12670
> {quote}
> We have set the following variables in sip.conf to ensure that mwi turns on and off in a timely fashion - 
> {quote}
> submaxexpiry=15
> subminexpiry=15
> {quote}
> I will be attaching the output of 'core show taskprocessors' after the system has been running for some hours, as well as extconfig.conf and the last 10000 lines of the debug log, with sip debug enabled
> This asterisk instance was compiled for debugging, we can provide any other information as necessary, and we can reliably reproduce this problem 100% of the time



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