snmpwalk in a threaded agent

[Nakamura, James]

Thanks for your help here. Sadly, this problem was happening with threads
disabled. Also, I am NOT calling
answer explicitly. I am only calling MibLeaf::get_request() as per the
template. What confuses me is that
your line: "You have received the request 1567562870 but you are trying to
answer request #30 also" are
you implying that I'm trying to reply twice? Could you please elaborate on
this as it sounds like this might
be the cause, but I don't fully understand what you mean here. 
 
A couple of other questions: I notice in the samples that the OID argument
in the constructors in the examples
don't have a leading . (e.g. 1.3.2.1.4.5 as opposed to .1.3.2.1.4.5) is
either correct or not?
 
I notice that the examples also have a MibGroup object constructed with all
of its children constructed below
that. At what "level" should this group be? The examples give the OID
"level" as 1. Should I create a MibGroup
that is set up to the "level" just above all of my mibs? Do I need to
construct the whole tree?
 
I'll keep poking around, thanks for your help.
 
-----Original Message-----
From: Jasvant Singh [mailto:jasvant.singh____wipro.com]
Sent: Tuesday, February 27, 2001 10:34 PM
To: AGENTPP
Subject: Re: snmpwalk in a threaded agent


Hi James, 

I have highlighted two lines in the log which seems to create the problem. 
You have received the request 1567562870 but you are trying to answer
request #30 also. 
Since this request does not exist it can't be answered. check from where
request #30 is being answered. 
It can be caused by multithreading try disabling threads. 
It looks like you are trying to answer the request yourself by calling
RequestList::answer() 
you should not do that. You should just call MibLeaf::get_request() instead
of answering request yourself. 
I think you are doing both. The request passed to you is not same as
received. 
That's way it contain a different request id. This number is just a counter
of number of requests received by agent. 


Another Tip: You can define BEGIN_LOG() to contain  printf("F>%s
L>%d\n",__FILE__,__LINE__); 
this will print filename and line number before every log. It will make
debugging easier. 


Regards, 
Jasvant. 


"Nakamura, James" wrote: 


I'm still working my way through getting my agent to work with an snmpwalk. 
The setup is a process talking via a tcp 
socket to my agent (using the agent++ library). I have it set up with 
threads to handle the fact that data is being 
passed asynchronously through the tcp socket. Anyway, when I do a snmpwalk, 
it gets through all of the snmp 
oids, but when it hits the first mib object that I create, it (or something)

gets confused: the logs indicate that 
the data that needed to be exchanged between the process and the agent 
occured correctly, with the following 
sequence is logged (meccmib is the derived mib object): 

20010227.16:15:13: 01493: (2)EVENT  : RequestList: request received 
(id)(siz)(fro)(ver)(com): (1567562870), (1), (206.64.210.9/48262), (SNMPv1),

(public). 
20010227.16:15:13: 01493: (6)EVENT  : main: GOT MIB REQUEST. 
20010227.16:15:13: 01527: (2)EVENT  : Agent: starting thread execution. 
20010227.16:15:13: 01527: (2)EVENT  : Mib: process request: getnext request,

oid: (30), (1.3.6.1.2.1.11.32.0). 
20010227.16:15:13: 01527: (3)EVENT  : Mib: process subrequest: getnext 
request, oid: (30), (1.3.6.1.2.1.11.32.0). 
20010227.16:15:13: 01527: (6)EVENT  : meccmib(get_request):: 
(MCDN.MCDN.REG_COUNT). 
20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess: got data: : 
(VMCDN.MCDN.REG_COUNT=0 ), (23). 
20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess:MibData:: 
(MCDN.MCDN.REG_COUNT=0). 
20010227.16:15:13: 01527: (6)EVENT  : DataFromProcess:calling handle 
request. 
20010227.16:15:13: 01527: (6)EVENT  : meccmib(handle_request from meccano)::

(MCDN.MCDN.REG_COUNT=0). 
20010227.16:15:13: 01527: (3)EVENT  : RequestList: finished subrequest:: 
(0), (1.3.6.1.4.1.1102.1.3.6.30), (0). 
20010227.16:15:13: 01527: (2)EVENT  : RequestList: answer request: (30). 
20010227.16:15:13: 01527: (4)EVENT  : RequestList: request answered: 
(1567562870), (30), (206.64.210.9/48262), (0), (0). 
20010227.16:15:13: 01527: (1)ERROR  : RequestList: done: can't find request 
id: (30). 
20010227.16:15:13: 01527: (2)EVENT  : Agent: finished thread execution. 


The disturbing line is the "can't find request id" which implies that the 
request object got blasted along the way. 
It's interesting to note that the "request answered" deletes the request 
after the conclusion which probably is 
the reason why the request is no longer available. Why is the library now 
trying to access an object that appears 
to have been freed? Is there something amiss in the way I built my mib 
objects (and placed them into the tree)? 


The effect is that the snmpwalk only gets to the snmp data and then stops 
without getting any of the process 
specific data. Any ideas what's going on here? 


James Nakamura 
naka at metricom.com 
Work like you don't need the money. Love like you've never been hurt. Dance 
like nobody is watching. -- Mark Twain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20010228/e27993b9/attachment.htm