[snmp] snmpv3 context receiver thread destoyed
Josh Bers
jbers at bbn.com
Tue Apr 3 16:06:48 BST 2007
Birgit,
Yeah, I'd prefer an official release but if this fixes the problem we might
update to the CVS head... Did you and/or Tim take a look at the debug
output? Any ideas about what's going wrong?
> To answer your question:
> The 5 retries all have the same request Id. The first one
> that comes back is "accepted" (for better word of it), the
> next ones are ignored.
> In the later case you would get a message: Pdu of msgId XXX
> is already answered.
>
Birgit the problem that I'm expecting is that many Discovery PDU's with
different msgId's will be outstanding (being retried) say req id 55, 57, and
59. Let's say the original request of 59 comes back because the agent
becomes reachable. Now retry # 2 for reqid 57 goes through... Does the stack
handle this case of multiple USM discovery PDU's with responses? What
happens to the timeline, engine id, etc.
Josh
> -----Original Message-----
> From: snmp-bounces at snmp.westhawk.co.uk
> [mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Birgit
> Arkesteijn
> Sent: Tuesday, April 03, 2007 1:07 PM
> To: List for discussion of the Westhawk SNMP stack
> Subject: Re: [snmp] snmpv3 context receiver thread destoyed
>
>
> Hi Josh,
>
> One of the last changes I made to the code (and checked it in on
> SourceForge) was that the DiscoveryPdu (via the
> UsmDiscoveryBean) uses the retry_intervals from the original pdu.
>
> I know it isn't an official release, but you could check out
> the code from SF and use that one. See
> http://sourceforge.net/projects/westhawksnmp/
>
>
> To answer your question:
> The 5 retries all have the same request Id. The first one
> that comes back is "accepted" (for better word of it), the
> next ones are ignored.
> In the later case you would get a message: Pdu of msgId XXX
> is already answered.
>
> Hope this answers your question.
>
> Cheers, Birgit
>
>
> On Fri, Mar 30, 2007 at 04:38:15PM -0400, Josh Bers wrote:
> > Birgit and Tim,
> >
> > I believe that the problem I am seeing is compounded by the long
> > timeouts enforced by the UsmDiscoveryBean ~20 seconds..
> >
> > say I am polling for data every 5 seconds, but the device
> is down so
> > the discovery bean retries 4 times at 2 4 8 seconds
> >
> > that means that i'll have a backlog of USmDiscoveryBean requests
> > outstanding when one finally, goes through..and then another.. How
> > does the stack respond to multiple USM discovery requests
> coming back
> > from the same snmp agent?
> >
> >
> > Josh
> > _______________________________________________
> > snmp mailing list
> > snmp at snmp.westhawk.co.uk
> > http://snmp.westhawk.co.uk/mailman/listinfo/snmp
>
> --
> -- Birgit Arkesteijn, birgit at westhawk.co.uk,
> -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK
> -- Company no: 1769350
> -- Registered Office:
> -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK.
> -- tel.: +44 (0)161 237 0660
> -- <URL: http://www.westhawk.co.uk>
> _______________________________________________
> snmp mailing list
> snmp at snmp.westhawk.co.uk
> http://snmp.westhawk.co.uk/mailman/listinfo/snmp
>
More information about the snmp
mailing list