[asterisk-bugs] [JIRA] (ASTERISK-28084) app_queue: QueueMemberStatus Event flooding AMI
Asterisk Team (JIRA)
noreply at issues.asterisk.org
Wed Aug 28 11:57:55 CDT 2019
[ https://issues.asterisk.org/jira/browse/ASTERISK-28084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asterisk Team updated ASTERISK-28084:
-------------------------------------
Target Release Version/s: 17.0.0
> app_queue: QueueMemberStatus Event flooding AMI
> -----------------------------------------------
>
> Key: ASTERISK-28084
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-28084
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/ManagerInterface, Core/Stasis
> Affects Versions: 13.23.1
> Environment: Centos 7
> Reporter: Andrej
> Assignee: Richard Mudgett
> Labels: patch
> Target Release: 13.24.0, 15.7.0, 16.1.0, 17.0.0
>
> Attachments: jira_asterisk_28084_v13.patch
>
>
> Hi everybody,
> I’d kindly ask for your help - we have an asterisk 13 installation with approximately 100 queues and 30 agents -- all agents are dynamic queue members in multiple queues. When a call comes into any of the queues and asterisk cycles through available agents, we get an error:
> [2018-09-28 19:40:51] WARNING[107251]: taskprocessor.c:895 taskprocessor_push: The 'subm:manager_topic-00000006' task processor queue reached 3000 scheduled tasks again.
> Negative effect is that AMI dependent applications (like our CRM) start lagging.
> Same thing happens when agents login/logoff. I’ve first noticed this problem with asterisk version 13.19, but it’s also present in 13.20 and 13.21. and 13.23.1. Last working version was therefore 13.18.
> I can easily reproduce this with test system without any serious load. If this matters, we are using freepbx and dynamic queue members.
> I strongly suspect that problem is related to huge amount of AMI messages QueueMemberStatus (flooding the AMI? Stasis? I am no expert, not sure about this part).
> I've tried to filter QueueMemberStatus with eventfilter=!Event: QueueMemberStatus in all defined manager users, but that did not solve the problem, asterisk warning messages (and lag) was still there.
> Then I've tried to use stasis.conf to decline queue_member_status_type events and this did get rid of warning messages (and lag), but induces memory leak - with every call there is higher memory consumption until asterisk uses all the memory and OOM killer kicks in.
> Thanks,
> Andrej
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list