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. Thanks! -- cc -Wall The Lodging Company http://www.skihills.com/ OpenPGP Public Key ID: 0x262208A0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080317/4a4aba36/attachment.pgp
On Monday 17 March 2008 15:44, C. Chad Wallace wrote:> 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.In the source, find the line matching ao2_container_alloc, and change the first argument from 37 to 1. This will make the container behave exactly like a linked list. -- Tilghman
On 3/17/08, C. Chad Wallace <cwallace at lodgingcompany.com> 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, atis at iq-labs.net Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835