[asterisk-bugs] [Asterisk 0017354]: [patch] Queue member considered available when paused, causing high weight queue to block low weight queue

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17354 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17354
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-1506 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 263766 
Request Review:              
====================================================================== 
Date Submitted:             2010-05-18 10:31 CDT
Last Modified:              2010-07-07 12:41 CDT
====================================================================== 
Summary:                    [patch] Queue member considered available when
paused, causing high weight queue to block low weight queue
Description: 
Issue https://issues.asterisk.org/view.php?id=13220 addresses a problem in which
a call ringing on a member on a
high weight queue and who is also in a low weight queue blocks the low
weight queue.  I believe the fix for this is incomplete in that it fails to
treat a paused member as being unavailable.  This can happen even if only
the one member is on both queues.

Scenario.  Given a high weight queue and a low weight queue both with the
same single member, and the member is paused on the high weight queue,
present a call first to the high weight queue and then to the low weight
queue.

Expect.  The first call is stalled on the queue.  The second call is
answered.

Get.  Both calls are stalled until the first call is abandoned.

If the roles of low and high weight queue are reversed, this works as
expected.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013220 [patch] Calls in high-weighted queue bl...
====================================================================== 

---------------------------------------------------------------------- 
 (0124314) davidw (reporter) - 2010-07-07 12:41
 https://issues.asterisk.org/view.php?id=17354#c124314 
---------------------------------------------------------------------- 
I've uploaded a patch against trunk to handle this problem.  When it is
checking for a member being able to take work in a higher priority queue,
it now first tests whether it is paused in that queue, a relatively cheap
test, then, after determining how many available agents there are in the
queue, it discounts a conflict if there are none.

This is a belt and braces approach, as the only reason (except maybe a
race) I can see for having the number of available members be zero, after
we have established that the member is nominally available for the first
queue and is also in the second queue, is that they are paused in the
second queue.

If one really does go to the second test and the member really isn't
available, but others are, and there is more work than members, the
presumption is that those other members will take up work that is on offer
until there are no available members left, and a retry on the first queue
will then succeed.


This patch also applies to 1.6.2, but Local channels, which I used to
simplify the test configuration, are not well behaved, as they have an
invalid status.  Or real world case is with agents.

Also, although it doesn't invalidate that the test shows a problem with
the unpatched code, the test behaves more realistically if one sets
ringinuse=no for both queues. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-07 12:41 davidw         Note Added: 0124314                          
======================================================================