[Asterisk-bugs] [Asterisk 0010127]: Queue timeouts are considerably higher than expected

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10127 
====================================================================== 
Reported By:                bcnit
Assigned To:                qwell
====================================================================== 
Project:                    Asterisk
Issue ID:                   10127
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.6 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             07-05-2007 20:31 CDT
Last Modified:              07-09-2007 13:11 CDT
====================================================================== 
Summary:                    Queue timeouts are considerably higher than expected
Description: 
A queue is defined as follows:

----------------------------
[testq]
timeout=10
retry=5
strategy=ringall
wrapuptime=0
maxlen=0
joinempty=no
leavewhenempty=yes
eventmemberstatus=no
eventwhencalled=no
reportholdtime=no
memberdelay=0
weight=0
timeoutrestart=0
autopause=no
member => SIP/100
member => SIP/101
member => SIP/102
----------------------------

When called with 'Queue(testq,n)':
1 - The phones ring for 10 seconds.
2 - There is 5 seconds silence
3 - The phones ring for 10 seconds.
4 - There is 5 seconds silence
5 - The call exits the queue on the time-out cycle

So, despite the queue having a timeout of 10 seconds, the call is in the
queue for 30.

When called with 'Queue(testq,n,,,10):
1 - The phones ring for 10 seconds.
2 - There is 5 seconds silence
3 - The call exits the queue (no mention is made of the time-out cycle).

So, despite coding an explicit 10 seconds timeout, the call is in the
queue for 15.


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

---------------------------------------------------------------------- 
 putnopvut - 07-09-07 13:11  
---------------------------------------------------------------------- 
I just did some thorough investigation on this and here's what I've found:

The n option is dependent on the timeout parameter given to it in the
Queue() app call. The n option is ignored until the timeout has expired.
The thing is, app_queue exits due to the timeout, NOT the n option. The
only way to actually make app_queue exit due to the n option being in
effect is to not specify a timeout, in which case it defaults to fifteen
seconds.

Now, since the check for the n parameter is where it is in code, it means
that if the start of the first cycle of calling the queue members and
waiting for the retry time occurs before the default timeout of fifteen
seconds has elapsed, then the n option will be ignored and so a second
round of calling the queue members and waiting through the retry time will
occur. This is the behavior you're seeing in your first scenario.

Since the intention of the n option is to only ring the queue members once
before moving on, this seems like broken behavior. A fix will be committed
shortly. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-09-07 13:11  putnopvut      Note Added: 0066823                          
======================================================================