Summary:ASTERISK-07665: Using 'n' option in Queue() causes static members list to be called twice
Reporter:Leif Madsen (lmadsen)Labels:
Date Opened:2006-09-02 10:12:54Date Closed:2011-06-07 14:07:45
Versions:Frequency of
Environment:Attachments:( 0) 7873.diff
( 1) debug-1.txt
( 2) debug-2.txt
Description:When using the 'n' option, the Queue() application cycles through the static members twice.

I would expect the members list to be called only once, however it always calls through twice.
Comments:By: BJ Weschke (bweschke) 2006-09-03 09:12:39

here's a new patch for u. hopefully this covers all the situations.

By: Leif Madsen (lmadsen) 2006-09-03 13:47:58

Well, as BJ and I discussed on IRC, his patch does correct the way the queue should be working, unfortunately its not what I was actually hoping the queue would do.

However, his patch does correct the bug at hand and works in testing.

By: Leif Madsen (lmadsen) 2006-09-03 22:16:48

OK I just really wanted to test my RSS aggregator, but to keep this on topic, in the 7873.diff patch BJ has currently posted does include the 'c' option which is a feature of the queue() so it will exit after one cycle through the queue members as defined in queues.conf.

Oh I should also mention that the current implementation does not currently work, but I've already spoke with BJ on IRC.

By: Leif Madsen (lmadsen) 2006-09-06 17:43:48

I'm starting to get into a bit of a time crunch on this application, so if anyone happens to peruse this bug and thinks they could finish up the 'c' flag for me, I'd be willing to pay a bounty.

The one consideration BJ had mentioned was how do you know where the end of a cycle is when using 'random' -- I guess that depends if its a true random or a normalized random (where you randomly try each member of the queue once before you reshuffle the members list).

I'm not sure the effects this would have on leastrecent or fewestcalls -- I guess ideally those strategies would sort the members list (leastrecent followed by 2nd most recent, etc...) then exit after that first cycle.

If random is truly random, then a simple WARNING would suffice and it could exit after the timeout interval.

By: Leif Madsen (lmadsen) 2006-10-02 08:57:10

bweschke, we can probably close this eh? Is there any fix for this issue I reported? (I realize the original issue I was having is more of a feature request which won't be done at this time).

By: Anthony LaMantia (alamantia) 2006-10-10 14:40:13

closing, please repone this issue or submit a new one in the future if required.