[asterisk-bugs] [Asterisk 0012451]: join empty categories are not the same as leavewhenempty ones, joinempty probably wrong

noreply at bugs.digium.com noreply at bugs.digium.com
Mon Jun 2 08:30:13 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12451 
====================================================================== 
Reported By:                davidw
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   12451
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 114060 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-15-2008 11:14 CDT
Last Modified:              06-02-2008 08:30 CDT
====================================================================== 
Summary:                    join empty categories are not the same as
leavewhenempty ones, joinempty probably wrong
Description: 
Once one accounts for joinempty and leavewhenempty sort of having opposite
logical senses, one cannot match the effects of the values of these two
variables one for one.

joinempty = no matches leavewhenempty = yes

joinempty = yes matches leavewhenempty = no

However, joinempty = strict drops only for QUEUE_NO_REACHABLE_MEMBERS,
but

leavewhenempty = strict drops for both QUEUE_NO_MEMBERS and
QUEUE_NO_REACHABLE_MEMBERS.

====================================================================== 

---------------------------------------------------------------------- 
 davidw - 06-02-08 08:30  
---------------------------------------------------------------------- 
Using 1.4.20.1, for reference, the categorisation of the queue member
states is done by get_member_status, which was not modified by the current
patch.

This starts by assuming QUEUE_NO_MEMBERS.

It then scans the members, skipping any that are paused, or fail the
max_penalty condition. It also ignores any that are in an INVALID state,
although the test is done slightly differently.

If it finds an entry which is UNAVAILABLE, it changes its assumption to
QUEUE_NO_REACHABLE_MEMBERS.  UNAVAILABLE is how a logged out agent
presents.

If it finds a member in any other state, including busy, it returns
immediately with a result of QUEUE_NORMAL.  Note that doing anything else
for busy would mean that you never built up a queue!

If it runs out of members, it returns the current assumed state, which is
NO_MEMBERS unless it found an UNAVAILABLE entry.  Substituting logged out
for unavailable (although there are other causes of unavailable).  Finding
a logged out member will result in a NO_REACHABLE_MEMBERS result, but just
finding paused memebers will be treated as though there were no members at
all and result in a NO_MEMBERS result.  The presence of UNAVAILABLE members
doesn't change the fact that the paused ones are ignored, but the
NO_REACHABLE_MEMBERS state will then take precedence.

There is a slight anomaly if paused is combined with logged out, as paused
causes the member to be skipped and the logged out state is never detected.
 Thus, if all members are paused and logged out, you will get NO_MEMBERS,
which is enough to trigger the joinempty=no condition.

Busy is always an accept condition, because you would never build a queue
if you rejected just because the most available state was busy. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-02-08 08:30  davidw         Note Added: 0087637                          
======================================================================




More information about the asterisk-bugs mailing list