[asterisk-bugs] [Asterisk 0010320]: 1.4.9 changes to app_queue breaks 'joinempty=yes'

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10320 
====================================================================== 
Reported By:                jfitzgibbon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10320
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-27-2007 07:04 CDT
Last Modified:              08-09-2007 06:10 CDT
====================================================================== 
Summary:                    1.4.9 changes to app_queue breaks 'joinempty=yes'
Description: 
1.4.9 introduced changes to app_queue that change the logic associated with
exiting the queue due to a timeout.

The 1.4.8 logic would only ever be executed if the 'n' option was passed
to Queue(), as designed.

The 1.4.9 logic can be executed in the absence of the 'n' option if the
queue is empty.  The net effect is that a queue configured as
'joinempty=yes' with no members in it cannot be enqueued to in 1.4.9 -
calls will immediately be kicked back to the dialplan.  Depending on how
the dialplan was built, this could result in calls being unceremoniously
hung up if there are no further steps in the extension that called Queue()
====================================================================== 

---------------------------------------------------------------------- 
 jfitzgibbon - 08-09-07 06:10  
---------------------------------------------------------------------- 
I'm now running 1.4.10 with the updated version of app_queue.c from
yesterday.  Initial tests look good, and I'll report on any issues found
under real world traffic.  Given that this change restores the 1.4.7.1
logic regarding the 'n' option, I don't expect we'll see any problems. 
Every time we've seen issues with 1.4.8 or 1.4.9, we've immediately jumped
back to 1.4.7.1 and run without issue until the next time we've tried to
upgrade.

I'm still going to try to reproduce the "membercount = -1" situation I
observed, it's just taking a little time to build an environment.  My
hypothesis is that it doesn't happen when a queue just has one member in it
(since I've tested that scenario extensively).  Unfortunately, even to just
add one more agent makes the testing harness much larger, as I need to act
like up to 5 people at once (two agents, two callers tying up those agents
and one more caller attempting to enqueue).

I'm going to test the 9 variants of state ("not in use", "in use" and
paused") between two members, attempting to enqueue a new caller in each
case.

I've looked over all the places where q->membercount is manipulated and
nothing obvious jumps out at me.  I'm hoping this isn't a race condition
where membercount is being decremented in two threads at once (e.g. a
member being removed at the same time the queue is being reloaded), because
that will be much harder to track down.

Thanks 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-09-07 06:10  jfitzgibbon    Note Added: 0068650                          
======================================================================