[asterisk-dev] New agents does not get noted for waiting callers in the queue

Kevin P. Fleming kpfleming at digium.com
Mon Feb 13 09:26:32 CST 2012


On 02/13/2012 04:58 AM, Kristijan Vrban wrote:
> Hello, a customer criticised that when one or more caller are waiting
> in a queue (i use realtime queues) to get a free agent, and a new
> agent logged in,
> the new agent does not get the callers which are wating in the queue.
> Beacause when a caller enters the queue, the lookup which agents are
> available, passed only once when the caller enters the queue.
>
> So i made a simple hack, i added the "load_realtime_queue" function
> into "is_our_turn" which was the solution. Not a beauty, because every
> caller wainting
> in a queue produced in every run of "is_our_turn" a new database
> lookup. It would be lovelier, if there is one globel thread for the
> one queue that renew
> ,in a configurable interval, the available queue agents.

And the result would be non-realtime-queues... you'll be caching the 
queue and its member list in memory at all times, and forcing app_queue 
to constantly poll the database to see if it has changed. As you've 
already noted, this will likely cause performance problems.

> But the main problem i got stuck, plenty of times the caller get Moh
> dropout when "load_realtime_queue" get called in the "is_our_turn"
> function.
> As described in:
> https://issues.asterisk.org/jira/browse/ASTERISK-18989 I reckon that
> "load_realtime_queue" set some locks, which caused the
> res_timing_timerfd
> and res_rtp_asterisk issues as seen in the debug log which reason the
> Moh dropout.
>
> Question: how to design a function for app_queue that the new agents
> get noted? suggestions?

If such a function existed, how would it get triggered? There are only 
two options: either app_queue polls the realtime storage, or something 
tells app_queue to reload its configuration when it has been changed via 
some external mechanism. If that 'something' can tell app_queue to 
reload, then it should; that will always be far more efficient than 
polling the realtime storage for changes.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list