[asterisk-bugs] [JIRA] (ASTERISK-28084) QueueMemberStatus Event flooding AMI

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-28084:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

> 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: Asterisk Team
>              Labels: patch
>         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)