[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:              07-27-2007 07:32 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 - 07-27-07 07:32  
---------------------------------------------------------------------- 
Just posted this to -users, thought it might be useful to have it in this
record:

[...]

to clarify though the change made in 1.4.8 related to the 'n' option
doesn't seem to cause this.  1.4.8 (with or without the 'n' option) does
what I'd expect it to.  It's the logical overloading of go_on in 1.4.9 that
broke things.  go_on used to be a boolean - now it's a dual-valued
variable.  Sometimes it's compared just for it's truthfulness, and
sometimes it's used in a numeric comparison against the queues's
membercount.

If go_on had been left alone and a new variable used to store the
threshold to be compared against membercount, I don't think 1.4.9 would
have broken things, because go_on would (in my configuration) never have
been set to anything but zero, preventing the numeric comparison against
membercount from ever being performed. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-27-07 07:32  jfitzgibbon    Note Added: 0067973                          
======================================================================