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