On 3/17/08, C. Chad Wallace <[EMAIL PROTECTED]> wrote: > We just recently upgraded from Asterisk 1.2 to 1.4, and quickly noticed > a change in the behaviour of the queues--a change that we cannot live with. > > We've used AddQueueMember/RemoveQueueMember to manage logging into and > out of our queues for over a year now with Asterisk 1.2, and in that > version the queue members were sorted in such a way that the person who > had been logged in the longest would be the first one to get a call. > But when we deployed 1.4 last week, we noticed that the member list was > no longer sorted based on login time. It seemed to have a pre-set order > that members were always placed into. > > After looking at the code (apps/app_queue.c), I found the cause of this. > In 1.2, the members were stored in a linked list, so when someone > logged in, they were placed at the end, and when calls were handed out, > it was done starting at the front of the member list (or vice-versa, but > either way, it has the same effect). In 1.4, the member list was > changed to an "ao2_container", which apparently uses a hash table, and > iterates through the list in a fixed order, meaning one of our agents is > always the favourite for a call, and it is quite unfair. > > Now, I know that the ordering of members in the queue in 1.2 was not > documented, and it may not have even been intentional, but it was very > appropriate for our business model, and we'd like to find a way to get > it back. > > Is there a way to control the order in which the ao2_iterator returns > the items? Even a random distribution would be better than the > current--which always favours some agents over others. > > And before anyone mentions the "strategy" setting in queues.conf, I > should say that we use "leastrecent", but because of the ratio of agents > to queues in our business, the strategy doesn't come into effect > immediately. With many agents answering each queue, it takes a while > for each of them to get a call. Until then (which usually takes about > half of each day), the calls are distributed based on the ordering of > the member list. > > We have switched to the "rrmemory" strategy for now, but we've yet to > notice what effect that has--and our ideal would be to use "leastrecent" > along with the behaviour that Asterisk 1.2 exhibited. >
I would suggest adding: cur->lastcall = time(NULL); within create_queue_member() function. This will allow you speed bonus from hashtable in some places, and will make sure the login time gets registred. You can also consider updating lastcall in set_member_paused() - i'm having both of those. Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
