| Summary: | ASTERISK-28424: Task processor queue regularly fills up with subscriptions, using curl config and external mwi, test phone doesn't stay registered | ||
| Reporter: | David Moore (dmoore) | Labels: | |
| Date Opened: | 2019-05-22 10:19:41 | Date Closed: | 2019-06-08 12:00:04 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Subscriptions Core/Sorcery Core/Stasis Resources/res_config_curl Resources/res_mwi_external |
| Versions: | 13.26.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Debian 9 virtualized on vmware | Attachments: | ( 0) extconfig.conf.txt ( 1) fulllog_truncated.txt ( 2) taskproc.txt |
| Description: | 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 | ||
| Comments: | By: Asterisk Team (asteriskteam) 2019-05-22 10:19:41.824-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Benjamin Keith Ford (bford) 2019-05-22 10:44:14.134-0500 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? By: David Moore (dmoore) 2019-05-22 11:59:14.956-0500 There are 50 peers in the database. The output of 'sip show peers' is one peer, it's the only one registering. Yes, the only thing being done on the system is register and subscribe By: David Moore (dmoore) 2019-05-22 14:38:44.313-0500 I missed this before- bq. What's your process for loading via curl? We are using dbsep.cgi, which ships with Asterisk, it has not been substantially modified (only added logging) and it is connecting to a backend MySQL database. By: Benjamin Keith Ford (bford) 2019-05-24 14:36:03.012-0500 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. By: Asterisk Team (asteriskteam) 2019-06-08 12:00:02.949-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines | ||