[asterisk-bugs] [JIRA] (ASTERISK-22958) app_queue messes up member status on reload

[Rusty Newton (JIRA)]

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

Rusty Newton commented on ASTERISK-22958:
-----------------------------------------

If there is strange behavior here, then it would be nice to either fix it, or if anything have it documented as you said. I'm a bit confused on the original problem description.

I attempted reproduction, setting up queue members with local channels and their state interfaces derived from the hints in an included context.

After configuration, I made a call into the queue, answered it from one of the queue members and then reloaded app_queue.so while idle. I tried this several times and couldn't get any of the members to go into a strange or bad state. I tried with both types of includes.

A confusing aspect is that regardless of doing a "include =>" or a "#include", dialplan show does not show the context as an "Included context". Can you describe your dialplan configuration for this machine and what type of include you used?

If you don't expect reproduction to be possible, I'll just close this out as a another app_queue mystery!
                
> app_queue messes up member status on reload
> -------------------------------------------
>
>                 Key: ASTERISK-22958
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22958
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 11.6.0
>            Reporter: Jaco Kroon
>            Assignee: Rusty Newton
>
> Whenever members are not idle when app_queue reloads then the state goes into a bad state whereby calls will never be sent to those members.  I've also seen cases where the state will simply stop updating completely, at the moment:
> gabriel ~ # asterisk -rx "queue show uls-queue-support"
> uls-queue-support has 0 calls (max unlimited) in 'leastrecent' strategy (0s holdtime, 0s talktime), W:10, C:0, A:0, SL:0.0% within 60s
>    Members: 
>       X109/Conrad (Local/109 at xdial from hint:109 at hints) with penalty 20 (ringinuse disabled) (Not in use) has taken no calls yet
>       X105/Adriaan (Local/105 at xdial from hint:105 at hints) with penalty 20 (ringinuse disabled) (Not in use) has taken no calls yet
>       X104/ULS Pieter (Local/104 at xdial from hint:104 at hints) with penalty 30 (ringinuse disabled) (Not in use) has taken no calls yet
>       X103/ULS Kevin (Local/103 at xdial from hint:103 at hints) with penalty 100 (ringinuse disabled) (Not in use) has taken no calls yet
>       X102/Jaco Kroon (Local/102 at xdial from hint:102 at hints) with penalty 200 (ringinuse disabled) (Not in use) has taken no calls yet
>       X111/Nadine (Local/111 at xdial from hint:111 at hints) with penalty 10 (ringinuse disabled) (Not in use) has taken no calls yet
>    No Callers
> Even though I (X102) is currently on the phone.  The hint, according to the dialplan is:
> [ Included context 'hints-uls' created by 'pbx_config' ]
>   '102' =>          hint: SIP/102                                 [pbx_config]
> The fact that it's an included context seems to be what's throwing it off.  Thus on reload I'm guessing a slightly more intelligent mechanism needs to be used to set state_exten, or alternatively the state should not be duplicated into the member structure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira