asterisk users - Jul 2007 - Problems with new logic being 'n' option to Queue in 1.4.9

I am experiencing a change in behaviour of my Queues in 1.4.9 vs 1.4.8.

I do not pass the 'n' option to any call to Queue() in my dialplan.  Yet
since I upgraded to 1.4.9, I have occasionally seen this on my console:

    -- Nobody picked up in 20000 ms
    -- Exiting on time-out cycle

That log message "Exiting on time-out cycle" is exclusive to the logic
in
app_queue meant to deal with the 'n' option.  If you don't pass
'n', you
should never see it.

1.4.8 code:

                                /* exit after 'timeout' cycle if
'n' option
enabled */
                                if (go_on) {
                                        if (option_verbose > 2)
                                                ast_verbose(VERBOSE_PREFIX_3
"Exiting on time-out cycle\n");
                                        ast_queue_log(args.queuename,
chan->uniqueid, "NONE", "EXITWITHTIMEOUT",
"%d", qe.pos);
                                        record_abandoned(&qe);
                                        reason = QUEUE_TIMEOUT;
                                        res = 0;
                                        break;
                                }

1.4.9 code:

                        /* exit after 'timeout' cycle if 'n'
option enabled
*/
                        if (go_on >= qe.parent->membercount) {
                                if (option_verbose > 2)
                                        ast_verbose(VERBOSE_PREFIX_3
"Exiting on time-out cycle\n");
                                ast_queue_log(args.queuename,
chan->uniqueid, "NONE", "EXITWITHTIMEOUT",
"%d", qe.pos);
                                record_abandoned(&qe);
                                reason = QUEUE_TIMEOUT;
                                res = 0;
                                break;
                        }

In both versions, the variable 'go_on' starts off set to 0, and only
gets
set if you pass the 'n' option to Queue().  The manner in which it gets
set
differs between 1.4.8 and 1.4.9, but it is only when you pass the 'n'
option, so it shouldn't matter.  In my configuration, go_on should always be
zero.

The logic check around go_on is what's worrying me.  In 1.4.8, go_on had one
of two values - 0 or 1.  If you never passed 'n' to Queue(), it was
always
0, so the block of code that takes you back to the dialplan on timeout can
never be executed.

In 1.4.9, if qe.parent->membercount is zero and you didn't pass the
'n'
switch, then you'll exit the queue as if you had timed out, even though you
never passed the 'n' option.  I haven't gone through the entire code
of
app_queue to see exactly how membercount gets manipulated, but it seems from
my log that these exitwithtimeouts events seem to occur right after an agent
has let their phone ring without picking it up (see the "nobody picked up
in
20000ms" message in my example above).

Is it possible for qe.parent->membercount to be set to zero in a queue where
all agents but one are on the phone and that one remaining agent lets their
phone ring without answering it?

-- 
j.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070726/35061dbb/attachment.htm

On 7/26/07, James FitzGibbon <james.fitzgibbon at gmail.com>
wrote:
>
>
> Is it possible for qe.parent->membercount to be set to zero in a queue
> where all agents but one are on the phone and that one remaining agent lets
> their phone ring without answering it?


I added some debug code to app_queue and ran a few tests.  The change in
app_queue in 1.4.9 breaks queues configured as "joinempty=yes".

If there are no members in the queue, the membercount will be 0.  A queue
configured as joinempty=yes should still allow calls to be enqueued in this
case.  Because go_on is zero and membercount is zero and the comparison is
"go_on >= qe.parent->membercount", any calls that attempt to
join a queue
without any members will immediately get kicked back to the dialplan.

    -- Executing [s at macro-enqueue:16] Queue("Zap/23-1",
"XXXXX|tW") in new
stack
    -- Started music on hold, class 'default', on Zap/23-1
[Jul 27 07:49:27] WARNING[31209]: app_queue.c:3458 queue_exec: about to
compare XXXXX's go_on (0) >= qe.parent->membercount (0)
    -- Exiting on time-out cycle

Though I can't seem to lock onto the circumstances, I also oberved this
breaking queues configured as "leavewhenempty=no".  I can't seem
to
replicate it using a single queue and a single member (on pause or on a call
or letting their phone ring through), but as I described in my first
message, I did see the "Exiting on time-out cycle" message last night
when I
had 4 people in the queue, all on a call, and one person didn't pick up
their phone.

Still, the joinwhenempty breakage should be enough to prompt a backout or
rapid fix for this.  Until recently, my dialplan didn't gracefully handle a
return from Queue() because all my queues were configured as
"joinempty=yes"
and "leavewhenempty=no".  Recently I added logic to kick users back to
the
IVR if Queue returns for any reason, but had I not made that change,
1.4.9would have resulted in my callers getting unceremoniously hung up
on if they
tried to join a queue without agents.

I'll go open a bug report.

-- 
j.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070727/fa33bc5b/attachment.htm