On 11/11/2010 04:50 PM, Robert Story wrote: > On Thu, 11 Nov 2010 08:04:18 +0200 Timo wrote: > TT> Right. I'd assume the RightThing(tm) is to on first MIB request to do > TT> full load and start listening changes, and after a timeout stop > TT> listening changes. We'd have then fully dynamically working system. > > sounds good, as long as the listening part is optional.
Okay. > TT> I'm wondering if I can do the following with the cache_handler: > TT> 1) on container_load we do full dump as usual, but also register for > TT> the netlink events for changes (using register_readfd() external fd > TT> handling) and finally a timer to unload cache/stop listening netlink > > The cache already has a timer, so that can be reused. Ah, of course. We have also the hooks for it so great. > TT> 2) on each of _get operations reset the "monitoring stop timer" > > A new cache helper flag could be added to bump the cache expiration timer. I > don't think a separate monitoring timer would be needed. Makes sense. > TT> 3) on netlink socket callback just go and directly update the local > TT> cache container using the regular CONTAINER_* > > Yep. You just have to have a way to get a hold of the cache. Another option is > to simply queue the netlink messages and not do any cache modifications until > a request comes in. This could be anew generic facility added to the cache > helper: cache updates, in addition to simply loading and flushing. The updates > could be immediate or delayed, and there could be thresholds for simply > triggering a flush and reload if too many updates come in... I'm not too excited about caching cache changes. I'd prefer to just go ahead and update the cache directly. I'll try to brew up some code to see how it works out in practice. - Timo ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
