How to sync a MibTable with an STL::vector?

Frank Fock Frank.Fock____t-online.de
Tue Apr 15 13:56:43 CEST 2003


Hi Stefan,

Stefan.Mueller-Wilken____resco.de wrote:
> 
>>>Unfortunately, my experiments show that MibTable::update(...) is called
>>>_on_every_ columnar _and_every_ row and not - as I would have expected
> 
> -
> 
>>That's not true. The "update" method is at least called once
>>per sub-request! It totally depends on the request!
> 
> 
> Hmmm. Well, it might not be true in the general case - it obviously is in
> mine, as far as I could interpret the traces I've collected. I have a debug
> message in my derived update method and it shows up nine times for a three
> column / three row table. Is there anything I can do about this or is it
> just a matter of a misbehaving NMS?
> 

It is not misbehaving but most likely not
very efficient ;-)
> 
>>>once per table. Additionally, the Request* changes on every call,
> 
> rendering
> 
>>That's also not true. The request pointer changes only if there
>>is a new request being processed.
> 
> 
> Again, this is just how I understood my message log: nine cells, nine
> update messages and nine different Request pointers in the log...
>
That depends on your NMS.

> 
>>No. You are free to implement whatever caching stragety
>>you like. It could be time based (refresh table only every
>>2 seconds), or you could do some examination of the request
>>and do some "intelligent" refreshing.
> 
> 
> Okay. Got that. But there is no single hook, is there? No method that's
> called only once before the table is walked? Sorry if I repeat myself, but
> MibTable::update seems to be called more than once while cycling through
> the table...
>
If you have an idea how one would detect when a
table is walked, then such a method could be written.
But in real life SNMP, a request can contain subrequests
to more than one table and these tables may have different
refresh time constrains. That's why I did not implement
a generic solution, because although it could seem helpful
in the first place, on the long run, it could inhibit a
proper solution.

> 
>>>Just to make things worse, I couldn't find any (complete) examples on
> 
> how
> 
>>>to sync Agent++ MibTables with databases or STL containers in posts to
> 
> the
> 
>>>lists or in the documentation. :-(
> 
> 
>>This is probably because there is no general way to
>>solve the problem, it depends on your requirements,
>>environment, and target system.
> 
> 
> Yeah, it sure does. Still, it would be great to have more demonstration
> code to get an impression about how others have come to a solution.
> 
> 
May be someone on the list has another example.
Have you already looked at the dynamic_table example
code?

Best regards,
Frank





More information about the AGENTPP mailing list