asterisk users - May 2008 - Realtime status feature - user feedback needed

Hello users,

I had developed several patches that allows to monitor current status
of queues/channels in realtime db. For example specifying realtime
family "channels" will make asterisk to keep current channel list in
realtime database engine. The same would be for queue callers and
queue members (already partially available in 1.4).

However I encountered a resistance from Asterisk developers, as they
don't wish to accept my patches - because they don't wish to support
another interface. As I read in Bug Guidelines, if enough users
request this, it should make into asterisk, so I'm asking You to
express Your opinion on those features.

*** So, realtime status - what's this all about?
Basically you get output of "show channels", "show queues",
etc
directly in Realtime table (Realtime = database engine system for
Asterisk). So, Asterisk will automatically update database upon any
changes of channels or queues.

*** Why would You need that?
In beginning I created this in order to deal with large amount of
monitoring software. If there's lot of users monitoring status, some
kind of cache should be put into place. With current Asterisk
interfaces this would mean either inquiring current status or
developing a daemon that follows up all events and collects them to
keep current picture always ready. I just decided to move this layer
to database engine, which deals really good with this stuff.

*** Rapid development of monitoring tools
What it takes to create custom monitoring tool now? AMI event
listener? AJAX page that gets changes from built-in webserver?
All this takes lot of time to learn and start using. Adding just few
config lines in "extconfig.conf" would allow to automatically populate
database with current status - so it's accessible easily from any
programming language. All the info is "just there", no need for
processing or analyzing.

*** Performance / Scalability
Inquerying queue status means that there is lock put on queue list,
all queues are traversed, information gathered and then returned. If
lot of instances of monitoring software need to have this information,
it's obvious that this would mean too much locks. So, as database
update is thrown whenever some change is happening, it means that no
additional locks are created for monitoring purposes. Transaction is
sent to database engine, which keeps relatively small tables of
current status. Then any number of clients can access data directly
without any locking. Even 200 concurrent calls with 10 new calls per
minute would still be a tiny load for MySQL. This can also be scaled
by moving database to another machine, thus allowing more raw CPU
usage for Asterisk.

*** Development maintenance
Those changes doesn't introduce any new functions in asterisk code.
They utilize currently available "Realtime" engine which is meant for
storage of configuration data. This just extends use of this engine
also for status data, so maintenance of this interface should not take
lot of work.

*** Current patches
If You are interested in using those changes right away, here are some
backports for 1.4:

Channels: http://ftp.iq-labs.net/realtime_channels/
Queue callers: http://ftp.iq-labs.net/realtime_queue_callers-1.4/
Queue members: work in progress, needs some refactoring and
optimization to make that effective.
Meetme: planned, no patches yet

To use any of those patches, you will need to add backport of
store/destroy to 1.4:
http://ftp.iq-labs.net/realtime_store_destroy-1.4/

*** Supporting this feature
If You find that those features would be good for merging into
Asterisk, please write a comment in bugtracker:
http://bugs.digium.com/view.php?id=12556

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

Atis Lezdins schrieb:
> I had developed several patches that allows to monitor current status
> of queues/channels in realtime db.
[...]

+1 as long as the user can choose whether they want realtime status
data in the database.
> *** Supporting this feature
> If You find that those features would be good for merging into
> Asterisk, please write a comment in bugtracker:
> http://bugs.digium.com/view.php?id=12556
Not sure if the bugtracker is the right place to write "me too"
for a feature request type of "bug".


Gr??e,
Philipp Kempgen
-- 
Asterisk-Tag.org 2008, May 26th/27th  -> http://www.asterisk-tag.org
amooma GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Gesch?ftsf?hrer: Stefan Wintermeyer, Handelsregister: Neuwied B14998

On Wednesday 07 May 2008 16:11:05 Atis Lezdins wrote:
> However I encountered a resistance from Asterisk developers, as they
> don't wish to accept my patches - because they don't wish to
support
> another interface. As I read in Bug Guidelines, if enough users
> request this, it should make into asterisk, so I'm asking You to
> express Your opinion on those features.
That's not quite correct, either.  First of all, the correct forum for this
is
the -dev list, where we discuss development issues.  Second, we gave you
an alternative way to do this.  You could do this with AMI, with the addition
of a single query to access current state, then monitor status continuously
for updates.  And third, it doesn't make a difference how many users request
a particular interface -- the development team has to maintain it afterwards,
and if you're proposing a new interface, you need to convince the
development
team that it's worth the extra hassle -- not the users.

So we're not opposed to the concept; we are opposed to the particular
interface that you chose to use.  Modify it, and it will make its way back
into Asterisk.  Stubbornly stamping your foot and insisting that you have
the right way, and the status quo will remain.
> *** Supporting this feature
> If You find that those features would be good for merging into
> Asterisk, please write a comment in bugtracker:
> http://bugs.digium.com/view.php?id=12556
Please don't.  We've already discussed this to enough detail, and if you
choose to modify your code, it will show up in the next major release of
Asterisk.

-- 
Tilghman