GETBULK problem

[Ram Krishnaswamy]

Hello Frank,

Thanks for your reply. 

I did increase the timeout (to 2 minutes with 3 retries) and it still times
out. 

One test which I ran was to get the entire table using getnext instead of
getbulk and it works. So the question is why does getnext work whereas
getbulk or walk (which uses getnext anyway right) doesn't?

Regarding the update mechanism I use, I query the agent only after I know
for sure that the updates have occurred (for testing purposes only). Once I
start the agent, I initialize the table with default values. I then start
all the processes and then update the table. Once this is done, I print the
contents of the table. All the data that is supposed to there is present.
Only after I do all of this, do I start querying the table from the
MibBrowser. So I don't think that there might be a dead lock situation. If
there is, isn't it fair to say that getnext won't work in the 1st place?

In the list of processes, I have a JINI, RMID and JMS started in the same
order. For some reason, adding RMID causes the above problem with getbulk. I
had the rmmagent start just with RMID and there is NO problem. I started
rmmagent with just JINI and JMS and there is no problem either. This is
really puzzling to me why when all of three are started, the getbulk or walk
does not work although getnext works. Moreover, there is a start delay for
each process when it starts. So it is not as if they all start at the same
time. So the update on the table for each one of them does not happen at the
same time. 

The bottom line is, how do I try to find out if it is a getbulk problem? The
debug statements put up on the screen does not point to any problem. Any
pointers would be appreciated. Thanks.

Ram

-----Original Message-----
From: Frank.Fock____t-online.de [mailto:Frank.Fock____t-online.de]
Sent: Saturday, July 28, 2001 7:46 AM
To: Ram Krishnaswamy
Cc: 'agentpp-dl____agentpp.com'
Subject: Re: GETBULK problem


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