[asterisk-users] Problems with new logic being 'n' option to Queue in 1.4.9

[James FitzGibbon]

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