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

[Andrej (JIRA)]

Andrej created ASTERISK-28084:
---------------------------------

             Summary: 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


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)