|Summary:||ASTERISK-09355: Add MIB object astNumChanBridge to res_snmp|
|Reporter:||Jeff Gehlbach (jeffg)||Labels:|
|Date Opened:||2007-04-30 11:01:31||Date Closed:||2007-07-11 19:59:25|
|Environment:||Attachments:||( 0) 9637_followup.patch|
( 1) astNumChanBridge-trunk.patch
|Description:||The MIB in its current state has many shortcomings, one of which is that there's no scalar object to count the number of currently bridged channels in the system. This patch adds a counter object with this statistic. The thinking is that the number of bridged channels is a fair indicator of the overall call load in the system.|
I plan a follow-up patch that adds a table with similar stats that is indexed by technology type. That will allow tracking the number of bridged IAX2 channels vs. the number of Zap channels.
|Comments:||By: Jeff Gehlbach (jeffg) 2007-04-30 12:44:55|
This bug got submitted under SIP because that's what I had my default project set to. It should be categorized probably as Core Asterisk, for lack of a better match. Not sure it's possible for me to make that change :(
By: Russell Bryant (russell) 2007-06-08 16:31:34
This functionality has been merged into trunk in revision 68507. Thanks!
One note, be sure to use tabs instead of spaces for indentation in the future. :)
By: Jeff Gehlbach (jeffg) 2007-06-13 09:00:10
The original patch failed to walk the channel list correctly, and had a couple other problems. Will attach a new patch, against current trunk, to correct these issues.
By: Russell Bryant (russell) 2007-06-13 10:32:51
The only functional change I see in your patch is changing long_ret to be static. I can see why that is necessary. However, are you *sure* that it is safe? It is ensured that this function will never be called by more than one thread?
By: Jeff Gehlbach (jeffg) 2007-06-13 10:55:05
I think there should only ever be one thread for the SNMP (sub)agent. At any rate, every other unsigned long in res/snmp/agent.c is declared static.
Regarding thread safety in the Net-SNMP framework:
Summary: "confine your SNMP stuff to a single thread and you'll probably be fine".
By: Russell Bryant (russell) 2007-06-13 11:05:06
Fixed in trunk in rev 69067, thanks!