The purpose of the handler is to cache information from the lower sources, store it in an extremely fast searchable hash-tree, and return it to the agent any time new requests come in. The stash_cache handler needs to be injected above any table helper that takes care of normally returning data. Once the data is cached, it won't query the lower table handler again until the cache expires.
Handler Types that Support The stash_cache
Right now the stash_cache is only usable with these handler types:
In the modules code you can inject the handler as follows (usually after it's fully registered):
netsnmp_inject_handler_before(tptr->reginfo, netsnmp_get_bare_stash_cache_handler(), _clone_handler(handler), "table_iterator");
You can also use the netsnmp_get_timed_bare_stash_cache_handler(...) function to create a handler with more specific timing parameters.
For tables that are implemented using a compliant handler, you can insert the stash cache at run-time using the following snmpd.conf syntax:
injectHandler stash_cache TABLE_NAME table_iterator
The table_iterator portion tells snmpd to inject the handler before the table_iterator part of the chain, which is required. Substitute a different handler type if the module is implemented using a different handler type.
Internally, the stash cache intercepts GET and GETNEXT requests being sent down the handler chain. It will then:
- If the cache is present and recent, it will answer it and not call the lower handlers
- If the cache is out of date, it will create a new request with a special internal mode (MODE_GET_STASH)). The lower helper should extract the passed in oid_stash pointer and fill it with a complete copy of the table's data. IE, the lower handle doesn't just return a portion of the information, it needs to return everything!
Graphical Handler Chain
Graphically, before the stash_cache gets inserted the chain likely looks like this: