[asterisk-users] Order of queue member list

[C. Chad Wallace]

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