[asterisk-bugs] [Asterisk 0012556]: [patch] Realtime queue callers

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12556 
====================================================================== 
Reported By:                atis
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12556
Category:                   Applications/NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 114874 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-30-2008 06:23 CDT
Last Modified:              05-01-2008 10:58 CDT
====================================================================== 
Summary:                    [patch] Realtime queue callers
Description: 
This patch adds new realtime family for queue callers. app_queue will do a
realtime store for new caller, and destroy for one left. 

This allows better monitoring of queue callers from multiple clients at
same time, as there is no need for caching of AMI commands, all is kept in
Realtime, and multiple clients are handled by database engine.


====================================================================== 

---------------------------------------------------------------------- 
 vieri - 05-01-08 10:58  
---------------------------------------------------------------------- 
How would you design the "appropriate AMI command for querying queue
status" and avoid potential deadlocks while gathering data in "real-time"?
(or do you believe deadlocks are not an issue?) What would trigger the
update of this data? The patch proposed by Atis would suggest app_queue ->
SQL DB (which in turn could have triggers on table data change running
external custom apps/events, etc... and that's something the end user would
administer).
How would I know when to run the new-to-come queue status command?
Could/is there a specific manager event for calls that enter and leave a
queue? That would allow my script to run the AMI command as little as
possible. But still, I'm wondering if asterisk could handle, say, 100 "show
queues" in a couple of seconds in the case of having, say, 50 callers
coming into the queue and another 50 going out (I would need to
custom-program timers in my script to avoid excessive AMI commands but that
in turn would slow everything down on a busy system).
So all I would personally require is that the AMI command be "robust" and
not lock or exhaust the system and at the same time have specific events
for queue entry/exit.
Before going into the design of this AMI command do you really think it's
the "best way to go"?

NB: I dont't care to use realtime for non-config purposes or not but all
I'm looking for is a pragmatic solution for busy systems to the problem
"who's on queue?". If there's a better place to discuss this then please
kindly point me to it.

Thanks. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-01-08 10:58  vieri          Note Added: 0086255                          
======================================================================