[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  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Thanks for the feedback. There are a lot of moving parts here, so let's try to narrow it down a bit if we can. Can you try isolating different parts of the problem to see if it's just one of these configurations that's causing the faulty behavior? For instance:
# Try loading from config files instead of realtime.
# Load from realtime without dbsep.
# Try chan_pjsip to see if it's channel driver specific.
# This might be more of a hassle, but maybe try with PostgreSQL to see if it's database specific.
I'm probably leaving something out, but that would be a good chunk of information to have.

> 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.txt, fulllog_truncated.txt, taskproc.txt
>
>
> 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)