proper OID for netsnmp_register_cache_handler

[khan...@emc.com]

Hello,

I've been experimenting with the caching (netsnmp 5.3.1-14.el5 yeah
RedHat) and I've noticed something that I do not understand. First of
all here are the details:

mod ::= t 1.3.6.1.4.1.1139.16.10 -- top level module OID
sw ::== { modMIB 1 } //SW_OID
swTable ::= { sw 1} // SWTABLE_OID

I'm basically just filling a table of RPM packages in swTable.

Here is my init routine:

55 void init_software(void)
56 {
57 static oid swTable_oid[] = { SWTABLE_OID };
58 static oid sw_oid[] = { SW_OID };
59 netsnmp_table_registration_info *table;
60 netsnmp_handler_registration *handler;
61 netsnmp_iterator_info *iter;
62 int rc = 0;
63
64
65 table =
SNMP_MALLOC_TYPEDEF(netsnmp_table_registration_info);
66 iter = SNMP_MALLOC_TYPEDEF(netsnmp_iterator_info);
67
68 handler = netsnmp_create_handler_registration("swTable",
69
swTable_handler,
70 swTable_oid,
71
OID_LENGTH(swTable_oid),
72
HANDLER_CAN_RONLY);
73 if (!handler || !table || !iter)
74 {
75 snmp_log(LOG_ERR, "malloc failed in init_software");
76 return;
77 }
78
79 netsnmp_table_helper_add_indexes(table, ASN_INTEGER, 0);
80 table->min_column = SWTABLE_MIN_COLUMN;
81 table->max_column = SWTABLE_MAX_COLUMN;
82 iter->get_first_data_point = swTable_get_first_data_point;
83 iter->get_next_data_point = swTable_get_next_data_point;
84 iter->table_reginfo = table;
85 netsnmp_register_table_iterator(handler, iter);
86
87
88 rc =
netsnmp_register_cache_handler(netsnmp_create_handler_registration
89 ("swTableCache", NULL,
90 sw_oid,
OID_LENGTH(sw_oid), 0), // fails if I use swTable_oid
91 SWTABLE_CACHE_TIMEOUT,
92 swTable_load,
swTable_free);
93
94 DEBUGMSGTL(("sdp", "netsnmp_register... = %d\n", rc));
95 }

The code above does work.

What I have noticed is that if I call netsnmp_register_cache_handler
with the OID for the table (swTable_oid) the function returns -1 and the
snmp walk returns nothing. If I use an OID one level up, either sw_oid
(.16.10.1) or mod_oid (.16.10) the routine returns 0 and the snmp walk
works. I don't understand why using the same OID for the two calls
(lines 68, 88) fail. My intent is to build a module which has a number
of caches, each with different tables and load routines, that's why I
cannot use the higher level OIDs so I thought that I can just use the
same OID as the table. Is the cause of the problem due to the two calls
to netsnmp_create_handler_registration for the same OID? I also tried
using the same handler from the first call to
netsnmp_create_handler_registration (line 68) and that also did not
work. Can someone please explain. Thanks.

---
Don Khan

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

[Dave Shield]

On 25 March 2010 00:55, <khan...@emc.com> wrote:

> Here is my init routine:
>
>     55 void init_software(void)
>     56 {

>     85     netsnmp_register_table_iterator(handler, iter);

This is registering a handler chain (based around the
iterator handler) for the specified OID - the root of the table.

>     88     rc = netsnmp_register_cache_handler(...);

This is registering a separate handler chain
(based around the cache helper) for the specified OID.
If you give it the root of the table, then the agent will
think
"But something is already looking after that OID.
I can't have two registrations fighting over the same request"
and reject the registration.

If you give it a different (higher) OID, then the agent
will be happy about having two separate registrations,
because they are looking after different OID trees.

The cache helper will be called for anything *before*
the table (and anything after it). So a global walk will
trigger the cache registration before it gets to the table.

But a walk that starts with the table OID, won't call the cache
registration handler chain, and will go straight to the
iterator-based one. So the data won't be loaded.

What you need to do is insert the cache helper into the
iterator-based handler chain, *BEFORE* registering this chain.

Have a look at the existing cache-based hrSWRunTable implementation
(in agent/mibgroup/host/hrSWRunTable.c) which does exactly this.

In fact, you'd probably be better off working with that code anyway,
rather than trying to re-write it yourself. Particularly using the
iterator helper, which is notoriously inefficient with large tables
(such as hrSWRunTable!)

Dave