[asterisk-users] Order of queue member list

[Atis Lezdins]

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