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:54	Date Closed:	2011-06-07 14:07:45
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
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.