[asterisk-bugs] [JIRA] (ASTERISK-18411) Queue members with hints for state_interface get stuck in "In Use" state.
Sébastien Couture (JIRA)
noreply at issues.asterisk.org
Mon Mar 10 10:28:06 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-18411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sébastien Couture updated ASTERISK-18411:
-----------------------------------------
Attachment: ASTERISK-18411_12.1.0.patch
ASTERISK-18411_11.8.0.patch
ASTERISK-18411_1.8.26.0.patch
The rationale behind this patch is that when a hint is used as a 'state_interface', app_queue should explicitly subscribe to it and become a watcher. That will prevent a dynamic hint from disappearing after a {{dialplan reload}} because Asterisk thinks it's not being "watched" by anything. We should also unsubscribe from the hint when the agent is removed from the queue.
This patch was mainly tested under Asterisk 11.7.0, but I have also ported it for 1.8.26.0, 11.8.0 and 12.1.0 (applies and compiles). I have tested this patch by using either a dynamic hint, a static hint, a local channel or a SIP device as a queue member's 'state_interface'. I have also added/removed the queue member both through Realtime and the CLI.
> Queue members with hints for state_interface get stuck in "In Use" state.
> -------------------------------------------------------------------------
>
> Key: ASTERISK-18411
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-18411
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Applications/app_queue
> Affects Versions: 1.8.5.0, 12.1.0
> Environment: 64 bit CentOS
> Reporter: Steven T. Wheeler
> Severity: Minor
> Attachments: ASTERISK-18411_11.8.0.patch, ASTERISK-18411_12.1.0.patch, ASTERISK-18411_1.8.26.0.patch
>
>
> We have noticed a few times in the last week that the state of queue members has been stuck in "In use" state even though their state interface says "Idle". When this happens the queue no longer routes calls to the agents. The only work around we have found so far is to delete the member entries from the realtime table and then add them back in.
> For instance the queue says all the members are In use:
> {noformat}
> asterisk -rx 'queue show queue1'
> queue1 has 0 calls (max unlimited) in 'linear' strategy (0s holdtime, 67s talktime), W:0, C:1, A:3, SL:100.0% within 86400s
> Members:
> Member 1 (Local/member1 at queue_calling/n) (realtime) (In use) has taken no calls yet
> Member 2 (Local/member2 at queue_calling/n) (realtime) (In use) has taken 1 calls (last was 6076 secs ago)
> Member 3 (Local/member3 at queue_calling/n) (realtime) (In use) has taken no calls yet
> Member 4 (Local/member4 at queue_calling/n) (realtime) (In use) has taken no calls yet
> No Callers
> {noformat}
> But their hints say otherwise:
> {noformat}
> asterisk -rx 'core show hints'
> member1 at blf : SIP/member1_softphon State:InUse Watchers 0
> member2 at blf : SIP/member2_softphon State:Idle Watchers 0
> member3 at blf : SIP/member3_softphon State:InUse Watchers 0
> member4 at blf : SIP/member4_softphon State:Idle Watchers 0
> {noformat}
> The queue member table configuration:
> {noformat}
> mysql> select * from Queue_Members;
> +----------+------------+------------+-------------------------------+------------------+---------+--------+
> | uniqueid | membername | queue_name | interface | state_interface | penalty | paused |
> +----------+------------+------------+-------------------------------+------------------+---------+--------+
> | 31229 | Member 2 | queue1 | Local/member2 at queue_calling/n | hint:member2 at blf | NULL | NULL |
> | 31230 | Member 3 | queue1 | Local/member2 at queue_calling/n | hint:member3 at blf | NULL | NULL |
> | 31231 | Member 4 | queue1 | Local/member4 at queue_calling/n | hint:member4 at blf | NULL | NULL |
> | 31232 | Member 1 | queue1 | Local/member1 at queue_calling/n | hint:member1 at blf | NULL | NULL |
> +----------+------------+------------+-------------------------------+------------------+---------+--------+
> {noformat}
> This issue occurs infrequently so a debug log would be huge, but if there is more information you need I will try to get it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list