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

[Andrej (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=245015#comment-245015 ] 

Andrej edited comment on ASTERISK-28084 at 9/29/18 1:42 AM:
------------------------------------------------------------

Wow, that was super fast - thank you very much, Richard.

I applied the patch on the test system and tested using sipp, leak seems to be gone. I've now used patch in production environment and will report back. Looks good.

Best regards,
Andrej


was (Author: tekach):
Wow, that was super fast - thank you very much, Richard.

Leak seems to be gone :)

Best regards,
Andrej

> 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: Unassigned
>              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)