I am experiencing a change in behaviour of my Queues in 1.4.9 vs 1.4.8.<br><br>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:
<br><br> -- Nobody picked up in 20000 ms<br> -- Exiting on time-out cycle<br><br>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.
<br><br>1.4.8 code:<br><br> /* exit after 'timeout' cycle if 'n' option enabled */<br> if (go_on) {<br> if (option_verbose > 2)
<br> ast_verbose(VERBOSE_PREFIX_3 "Exiting on time-out cycle\n");<br> ast_queue_log(args.queuename, chan->uniqueid, "NONE", "EXITWITHTIMEOUT", "%d",
qe.pos);<br> record_abandoned(&qe);<br> reason = QUEUE_TIMEOUT;<br> res = 0;<br> break;
<br> }<br><br>1.4.9 code:<br><br> /* exit after 'timeout' cycle if 'n' option enabled */<br> if (go_on >= qe.parent->membercount) {
<br> if (option_verbose > 2)<br> ast_verbose(VERBOSE_PREFIX_3 "Exiting on time-out cycle\n");<br> ast_queue_log(
args.queuename, chan->uniqueid, "NONE", "EXITWITHTIMEOUT", "%d", qe.pos);<br> record_abandoned(&qe);<br> reason = QUEUE_TIMEOUT;
<br> res = 0;<br> break;<br> }<br><br>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.<br><br>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.<br><br>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).
<br><br>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?<br><br>-- <br>j.