GETBULK problem

[Frank Fock]

Hi Ram,

Did you try to increase the timeout value for the GETBULK request?
Depending on the settings in your browser and the implementation
of your update mechanism you need much more time for processing
a GETBULK than a GETNEXT request.

I do not think that the GETBULK algorithm is the problem, because
it works fine in other applications/agents.

Did you check whether the agent responded (may be to late) to the
requests of the manager? If not, then there may be a dead lock
situation that may be caused by improper locking when updating
the tables. Please make sure that you always call Mib::lock_mib()
before you lock objects by ::start_synch().

Best regards,
Frank

Ram Krishnaswamy wrote:

> Upon further investigation, I think there might be a problem with GetBulk.
> Couple of things which I did after the following email were:
>
> - moved to 3.4.7a of agent++. This did not fix the problem.
> - print the contents of the snmp table in question after I start and update.
> This gives me correctly the number of rows plus all the data for all the
> rows. So the data is there but GetBulk processing is not working for some
> reason.
> - the getnext works
> - snmp walk does not work
>
> I am using MG-SOFT MibBrowser application.
>
> Thx.
>
> >  -----Original Message-----
> > From:         Ram Krishnaswamy
> > Sent: Friday, July 27, 2001 1:20 PM
> > To:   'agentpp-dl____agentpp.com'
> > Subject:      GETBULK problem
> >
> > Hello,
> >
> > I have a mib that contains two tables apart from other leaf objects. One
> > of those tables is a list of running processes that the agent can
> > start/stop. In some situations (given below), the getbulk request times
> > out. I am using MG-SOFT's MibBrowser to do a TableView (essentially a
> > bunch of getbulk requests). I am using agent++ 3.4.5a. I went through the
> > mailing list archive and found couple of articles (actually these articles
> > were for patch announcements) from last year that kind of relates to my
> > problem. But I am not sure.
> >
> > To give more description to the problem, when the agent starts up, it
> > initializes the two tables with relevant data and then starts all the
> > processes in the order given. Once started (this is on Windows NT), it
> > updates the snmp process table (one of the two tables mentioned above)
> > with pertinent information. Basically, this is being cached so that when
> > snmp requests come in, the retrieval will be fast. When getbulk requests
> > come in for this table, I can see that the agent is getting the requests
> > but the manager times out. I mentioned earlier that this happens only in
> > some situations. One such situation is explained below.
> >
> > I have 3 processes to start: JINI, JMS and RMID. There is no problem
> > starting but I cannot retrieve the process table information. If I take
> > out RMID then everything is okay. If I just have RMID as the only process
> > to start, it is okay too.
> >
> > Since the data is cached by the snmp tables, why does the getbulk requests
> > time out? What else can I look at to debug this problem? At this point I
> > feel it is the underlying agent++ code since the data is cached. Am I
> > wrong in thinking that?
> >
> > Ram Krishnaswamy
> > x1671
> >