[snmp] snmpv3 context receiver thread destroyed

[Birgit Arkesteijn]

Hi Josh,

I'm sorry to hear you're still having problems!

Yes, timeline /authentication info are cached separately from contexts 
(in stack.TimeWindow & stack.TimeWindowNode)

I have to jog my memory somewhat here ..
When you say that the problem persists, but a second request succeeds .. 
do you mean that the first request after you bring back the loopback 
interface fails, but the second succeeds? Whereas before no request 
succeeded, isn't it?

I think you'll have to email me a new debug output to see what's going 
on. I might not have time this week so see what's going on.


Yes, I did fix the problem mentioned by Steve (and Vincne).
I changed AbstractSnmpContext.java:

(cvs log):
revision 3.30
date: 2006/06/19 10:45:09;  author: birgit;  state: Exp;  lines: +40 -16
Added method freeTransmitters(). This code lived originally at the end
of run().
freeTransmitters() is called in run() and in destroy().


and I changed UsmDiscoveryBean.java
(cvs log):
revision 1.17
date: 2006/06/19 10:48:15;  author: birgit;  state: Exp;  lines: +8 -4
Added call to freeResources() twice in startDiscovery(), just before it
throws an Exception.



Cheers, Birgit


Josh Bers wrote:
> I did try the latest from CVS on sourceforge and the problem persists (same
> behavior as on 5_1).  Here is the email that I was talking about before
> (maillist doesn't like attachments).
> 
>>From Cochran, Steve A. [steve at more.net]
> Sent on 5/24/2006
> 
> Hi there,
> 
> I've been working on tracking down a couple of minor problems with the
> (otherwise excellent) Westhawk stack, one of which is somewhat similar to
> Vicne's.
> 
> Both bugs I've found are triggered only for SNMPv3 queries.  I noticed that
> if the initial GET or GETNEXT to an SNMPv3 host fails then several threads
> are left behind despite a call to destroy().
> 
> The first cause I found was in the UsmDiscoveryBean.  In it's
> startDiscovery() method there are two places where exceptions are thrown
> without first calling freeResources().  Thus the context created by the
> UsmDiscoveryBean itself is never destroy()ed.  Adding a call to
> freeResources() before each of these two throw statements seems to fix this
> issue.
> 
> After correcting this I discovered that I still had some transmitter threads
> left over when an SNMPv3 query failed.  My initial theory, which I exchanged
> email with Birgit about privately, was wrong as he thought. However, I
> *think* I have figured it out now.
> 
> The code for Pdu.send() first calls it's context's addPdu() which creates a
> Transmitter thread to send the data packet.  After addPdu() returns
> Pdu.send() calls the Pdu.addToTrans() method which actually starts the
> Transmitter thread to working.  The Transmitter thread calls the context's
> sendPacket() method, which in turn calls activate() to start
> AbstractSnmpContext's main thread.
> 
> This all works fine for SNMPv1/v2.  However, SnmpContextv3Basis supplies its
> own addPdu() which first calls AbstractSnmpContext's addPdu() and then
> starts up a UsmDiscoveryBean.  The problem is that UsmDiscoveryBean can
> throw a PduException if requests to the destination device time out. The
> exception isn't caught in either SnmpContextv3Basis.addPdu() or Pdu.send(),
> which means that Pdu.send() never completes and
> Pdu.addToTrans() never gets called.  Because of this the Transmitter never
> calls sendPacket() and sendPacket() never calls activate().  The active
> Transmitter threads are never cleaned up despite a call to destroy().
> 
> 
> protected boolean send(int error_status, int error_index) throws
> java.io.IOException, PduException {
>     if (added == false)
>     {
>         // Moved this statement from the constructor because it
>         // conflicts with the way the SnmpContextXPool works.
>         added = context.addPdu(this);   <-- EXCEPTION CAN OCCUR HERE!
>     }
>     Enumeration vbs = reqVarbinds.elements();
>     encodedPacket = context.encodePacket(msg_type, req_id, error_status,
>         error_index, vbs, snmpv3MsgId);
>     addToTrans();
>     return added;
> }
> 
> Sorry if I didn't do a very good job of explaining all this.  Long story
> short, I added a call to activate() in AbstractSnmpContext.addPdu() so that
> a Transmitter couldn't be created without first creating the main thread.
> It works for me, but Vicne's may be the more general solution.
> 
> Hope this is of some help to someone.  Otherwise I'm very happy with how
> well this SNMP stack works.  My thanks to everyone who has contributed to
> it.
> 
> Steve Cochran
> 
> 
> _______________________________________________
> snmp mailing list
> 

Josh Bers wrote:
 > Birgit,
 >
> I tried using the latest code from sourceforge, however, the problem 
> still appears. Strangely the first test fails (remote host not 
> reachable then reachable). If I run a subsequent test in the same JVM
> it succeeds. Is the timeline /authentication info cached separately 
> from contexts? If so that might explain why only the first test fails
> (since the subsequent ones don't have to send discovery PDU's).
> 
> I looked at some of the email archives and found a problem that 
> sounds related. There is a problem with transmitters not getting 
> cleaned up when an exception is thrown by discovery pdu (which is the
> case since it times out, right?). I am including the email. Was this
> ever fixed in the code?
 >
 > Thanks,
 >
 > Josh


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