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

Stefan.Mueller-Wilken____resco.de Stefan.Mueller-Wilken____resco.de
Tue Apr 15 10:36:55 CEST 2003






Hi Frank!

thanks for your reply.

> > 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?

> > 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...

> > my effords to ignore subsequent calls to update useless. And it seems
quite
> > a waste to make n x m calls to change the n rows of my m column table.
Do I
> > really have to completely zap the MibTable and rebuild it from scratch
on
> > every call? What's the proper way to do the trick?
>
> 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...

> > 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.


Cheers,
 Stefan




More information about the AGENTPP mailing list