On 11 February 2011 17:37, Eivind Naess <[email protected]> wrote:
> If you pay careful attention to the Interface_Scan_Init, it will dispose of
> the
> container for interface statistics and create a new container which in case
> triggers a full table re-load. Looking at the code for if-mib/ifTable, it uses
> the cache api which prevents this abuse when browsing the IF-MIB.
> I don't know of any API calls to cache a container in net-snmp. But a simple
> guard (see patch below) did prevent the condition that I am seeing and the
> snmpwalk finished without a problem. I am sure there are better ways to solve
> this, but I really hope that there's a possibility resolving this issue with
> this or an improved patch in future versions of net-snmp.
My main concern with this patch is that it completely ignores the existing
cache that is currently being used by ifTable (and _also_ by the ifXTable code).
A better approach would probably be to share the same cache here as well
(perhaps retrieving it using
netsnmp_cache_find_by_oid(ifTable_oid, ifTable_oid_size);
)
and inject this into the handler chain (as is done for ifTable/ifXTable)
That way you've got a consistent view of the interface statistics and
how quickly the cache times out.
Dave
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
