From jbers at bbn.com Tue Jan 23 13:48:25 2007 From: jbers at bbn.com (Josh Bers) Date: Tue Jan 23 18:50:58 2007 Subject: [snmp] deadlock when destroying a context Message-ID: <004201c73f1f$13c852a0$010010ac@JBERS2> When using a context to send a trap pdu my code runs into a thread deadlock in the stack. One thread is destroying the context while the other is transmitting. The stack should protect against this kind of deadlock 1 thread: Transmitter (locked) is in transmit and is trying to lock the Context to remove a Pdu 2 thread: Context (locked) is in destroy and is trying to lock the Transmitter to free it. AbstractSnmpContext.destroy() : // If run() has been started, then it will destroy the // transmitter threads when it finishes. Otherwise they must be // destroyed here. if (me == null) { freeTransmitters(); } meanwhile removePdu method is being called from the Pdu.transmit()... Looks like some better coordination scheme (finer grained sychronization) is needed here... See the thread dump below [junit] Full thread dump Java HotSpot(TM) Client VM (1.4.2_12-b03 mixed mode): ... [junit] Found one Java-level deadlock: [junit] ============================= [junit] "localhost_1162_0.0.0.0_v0_Trans0": [junit] waiting to lock monitor 0x08092c0c (object 0xab3f7cf0, a uk.co.westhawk.snmp.stack.SnmpContext) , [junit] which is held by "main" [junit] "main": [junit] waiting to lock monitor 0x08092b64 (object 0xab405f28, a uk.co.westhawk.snmp.stack.Transmitter) , [junit] which is held by "localhost_1162_0.0.0.0_v0_Trans0" [junit] Java stack information for the threads listed above: [junit] =================================================== [junit] "localhost_1162_0.0.0.0_v0_Trans0": [junit] at uk.co.westhawk.snmp.stack.AbstractSnmpContext.removePdu(AbstractSnmpContext. java:674) [junit] - waiting to lock <0xab3f7cf0> (a uk.co.westhawk.snmp.stack.SnmpContext) [junit] at uk.co.westhawk.snmp.stack.Pdu.transmit(Pdu.java:699) [junit] at uk.co.westhawk.snmp.stack.TrapPduv1.transmit(TrapPduv1.java:236) [junit] at uk.co.westhawk.snmp.stack.Transmitter.run(Transmitter.java:80) [junit] - locked <0xab405f28> (a uk.co.westhawk.snmp.stack.Transmitter) [junit] at java.lang.Thread.run(Thread.java:534) [junit] "main": [junit] at uk.co.westhawk.snmp.stack.Transmitter.stand(Transmitter.java:144) [junit] - waiting to lock <0xab405f28> (a uk.co.westhawk.snmp.stack.Transmitter) [junit] at uk.co.westhawk.snmp.stack.Transmitter.destroy(Transmitter.java:161) [junit] at uk.co.westhawk.snmp.stack.AbstractSnmpContext.freeTransmitters(AbstractSnmpC ontext.java:93 4) [junit] at uk.co.westhawk.snmp.stack.AbstractSnmpContext.destroy(AbstractSnmpContext.ja va:470) [junit] - locked <0xab3f7cf0> (a uk.co.westhawk.snmp.stack.SnmpContext) From thp at westhawk.co.uk Fri Jan 26 11:27:39 2007 From: thp at westhawk.co.uk (Tim Panton) Date: Fri Jan 26 11:33:31 2007 Subject: [snmp] deadlock when destroying a context In-Reply-To: <004201c73f1f$13c852a0$010010ac@JBERS2> References: <004201c73f1f$13c852a0$010010ac@JBERS2> Message-ID: On 23 Jan 2007, at 18:48, Josh Bers wrote: > When using a context to send a trap pdu my code runs into a thread > deadlock > in the stack. One thread is destroying the context while the other is > transmitting. The stack should protect against this kind of deadlock Ugh, thanks for spotting this! Do you have a small bit of test code that reproduces it ? (and any environment factors - dual core? etc) I'll take a look next week and see if we can come up with a patch... Tim. From jbers at bbn.com Fri Jan 26 09:08:14 2007 From: jbers at bbn.com (Josh Bers) Date: Fri Jan 26 14:10:35 2007 Subject: [snmp] deadlock when destroying a context In-Reply-To: Message-ID: <001201c74153$71f98f20$010010ac@JBERS2> Hi Tim, Here's some code snippets. Good luck reproducing it... It seems to occur when one thread is sending trap PDU's while another tries to destroy the context. I put a delay between my last trap send and the destroy and haven't seen it again.. (see lines marked // **uncomment to fix deadlock). Create a Timer and schedule a SendPDU timer task fairly frequently (> 1 per second) wait a bit, then call SendPDU.cancel() before canceling the Timer. Josh class SendPDU extends java.util.TimerTask { private int trapCode = SnmpConstants.SNMP_TRAP_LINKUP; volatile boolean isScheduled = false; private SnmpContext mContext; /** * */ public SendPDU() { super(); try { String host = TEST_MGMT_AGENT; if (TEST_MS_DEBUG_MODE) { host = "localhost"; } mContext = new SnmpContext(host, TRAP_PORT_NUMBER, "0.0.0.0", "Standard"); isScheduled = true; } catch (java.io.IOException exc) { System.out.println("IOException " + exc.getMessage()); } } public void run () { if (!isScheduled) { return; } testSendPdu(trapCode); if (trapCode == SnmpConstants.SNMP_TRAP_LINKUP) { trapCode = SnmpConstants.SNMP_TRAP_LINKDOWN; } else if (trapCode == SnmpConstants.SNMP_TRAP_LINKDOWN) { trapCode = SnmpConstants.SNMP_TRAP_COLDSTART; } else if (trapCode == SnmpConstants.SNMP_TRAP_COLDSTART) { trapCode = SnmpConstants.SNMP_TRAP_WARMSTART; } else if (trapCode == SnmpConstants.SNMP_TRAP_WARMSTART) { trapCode = SnmpConstants.SNMP_TRAP_AUTHFAIL; } else { // loop back to beginning. trapCode = SnmpConstants.SNMP_TRAP_LINKUP; } } private void testSendPdu (int trapCode) { if (trapCode == SnmpConstants.SNMP_TRAP_COLDSTART) { sendPdu(trapCode, coldStart, "coldStart"); } else if (trapCode == SnmpConstants.SNMP_TRAP_WARMSTART) { sendPdu(trapCode, warmStart, "warmStart"); } else if (trapCode == SnmpConstants.SNMP_TRAP_AUTHFAIL) { sendPdu(trapCode, authenticationFailure, "authenticationFailure"); } else if (trapCode == SnmpConstants.SNMP_TRAP_LINKDOWN) { sendPdu(trapCode, linkDown, "linkDown"); } else if (trapCode == SnmpConstants.SNMP_TRAP_LINKUP) { sendPdu(trapCode, linkUp, "linkUp"); } } private void sendPdu (int genericTrap, String trapType, String trapVal) { byte[] address = { 1, 1, 1, 1 }; try { synchronized (mContext) { TrapPduv1 pdu = new TrapPduv1(mContext); pdu.setIpAddress(address); pdu.setEnterprise("1.1"); pdu.setGenericTrap(genericTrap); pdu.setSpecificTrap(1); pdu.setTimeTicks(1000); System.out.println(pdu.toString()); System.out.println("Sending " + trapVal); if (genericTrap == SnmpConstants.SNMP_TRAP_LINKDOWN) { varbind downIf = new varbind(IF_INDEX_OID, new AsnInteger(1)); pdu.addOid(downIf); } else if (genericTrap == SnmpConstants.SNMP_TRAP_LINKUP) { varbind upIf = new varbind(IF_INDEX_OID, new AsnInteger(1)); pdu.addOid(upIf); } pdu.send(); } } catch (uk.co.westhawk.snmp.stack.PduException e) { System.out.println("PduException " + e); } catch (java.io.IOException exc) { System.out.println("IOException " + exc.getMessage()); } } /* * (non-Javadoc) * * @see java.util.TimerTask#cancel() */ public boolean cancel () { // **uncomment to fix deadlock // isScheduled = false; // workaround for deadlock in trap sending context // **uncomment to fix deadlock // synchronized (mContext) { // try { // mContext.wait(1000); // } catch (InterruptedException e) { // TODO Auto-generated catch block // e.printStackTrace(); // } mContext.destroy(); mContext = null; // } return super.cancel(); } /* * (non-Javadoc) * * @see java.lang.Object#finalize() */ protected void finalize () throws Throwable { if (mContext != null) { mContext.destroy(); mContext = null; } super.finalize(); } } > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Tim Panton > Sent: Friday, January 26, 2007 6:28 AM > To: List for discussion of the Westhawk SNMP stack > Subject: Re: [snmp] deadlock when destroying a context > > > > On 23 Jan 2007, at 18:48, Josh Bers wrote: > > > When using a context to send a trap pdu my code runs into a thread > > deadlock > > in the stack. One thread is destroying the context while > the other is > > transmitting. The stack should protect against this kind > of deadlock > > Ugh, thanks for spotting this! > > Do you have a small bit of test code that reproduces it ? > (and any environment factors - dual core? etc) > > I'll take a look next week and see if we can come up with a patch... > > Tim. > > > > > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > From thp at westhawk.co.uk Fri Jan 26 14:18:43 2007 From: thp at westhawk.co.uk (Tim Panton) Date: Fri Jan 26 14:25:42 2007 Subject: [snmp] deadlock when destroying a context In-Reply-To: <001201c74153$71f98f20$010010ac@JBERS2> References: <001201c74153$71f98f20$010010ac@JBERS2> Message-ID: <46B3A32A-A9A1-4EE9-9C98-1AABA030A19E@westhawk.co.uk> On 26 Jan 2007, at 14:08, Josh Bers wrote: > Hi Tim, > > Here's some code snippets. Good luck reproducing it... It seems to > occur > when one thread is sending trap PDU's while another tries to > destroy the > context. I put a delay between my last trap send and the destroy > and haven't > seen it again.. (see lines marked // **uncomment to fix deadlock). Ah, that makes sense - traps don't behave like other PDUs in that there is no retry so the Transmitter can be destroyed immediately after the first send() . I can from the code how it happens, but a tidy fix will have to wait 'till next week! Tim. From schen at ziplip.net Fri Jan 26 12:02:16 2007 From: schen at ziplip.net (Stephen Chen) Date: Fri Jan 26 23:13:56 2007 Subject: [snmp] deadlock when destroying a context In-Reply-To: <200701261425.l0QEPuh18949@snmp.westhawk.co.uk> Message-ID: <5FD52D0FD7C327449FD02EBBB79B331E042BCD@exchange01.ziplip.net> I didn't catch the beginning of this, but I encountered the same thing. > On 26 Jan 2007, at 14:08, Josh Bers wrote: > > > Hi Tim, > > > > Here's some code snippets. Good luck reproducing it... It seems to > > occur > > when one thread is sending trap PDU's while another tries to > > destroy the > > context. I put a delay between my last trap send and the destroy > > and haven't > > seen it again.. (see lines marked // **uncomment to fix deadlock). > > Ah, that makes sense - traps don't behave like other PDUs in that > there is no retry so the Transmitter can be destroyed immediately > after the first send() . I modified ResponsePdu to notify after send. This allows the observer to initiate context destruction. This looks similar to fillin and handleNoAnswer in Pdu. > I can from the code how it happens, but a tidy fix will have to wait > 'till > next week! > > Tim. While building an agent, I needed an AsnObjectId comparator or have AsnObjectId implement Comparable. I built an AsnObjectId comparator, which made get next requests easier to fulfill. Any thoughts about providing this in the stack? Any chance of providing a better example of an agent with get or get next response? The trap example just sends or receives, and I had to combine the two to get a working agent. My biggest wish would be for an agent that responds to Sun's JVM MIB and is extendable, as the one included in the 1.5 JVM is not extendable. Stephen Chen Senior Software Engineer ZipLip, Inc. schen@ziplip.net From jbers at bbn.com Mon Jan 29 20:54:50 2007 From: jbers at bbn.com (Josh Bers) Date: Tue Jan 30 01:57:19 2007 Subject: [snmp] slow snmp v3 discovery timeout Message-ID: <005f01c74411$a43ad3c0$010010ac@JBERS2> In working with snmpv3 contexts, I've found that sending a Pdu request to an agent is not there takes a long time to return ~19 seconds. When I looked into the code, it looks as though the v3 context is using a UsmDiscoveryBean to discover the v3 engineid and other parameters if that agent has never been contacted. The bean class uses the default timeout when sending the Pdu request for discovery. However, I had set a different retry_array on the original Pdu that is causing the discovery to be sent in the first place. It would make sense for the stack to use this retry array when sending the discovery Pdu as well. Or at a minimum provide a way to change the default retry array for v3 discovery. Perhaps there is another way to do this that won't take so long that I am missing.. suggestions welcome. Josh From Gejo.Thayil at aricent.com Tue Jan 30 10:53:50 2007 From: Gejo.Thayil at aricent.com (Gejo.Thayil@aricent.com) Date: Tue Jan 30 10:06:32 2007 Subject: [snmp] slow snmp v3 discovery timeout In-Reply-To: <005f01c74411$a43ad3c0$010010ac@JBERS2> Message-ID: >In working with snmpv3 contexts, I've found that sending a Pdu request to an >agent is not there takes a long time to return ~19 seconds. When I looked >into the code, it looks as though the v3 context is using a UsmDiscoveryBean >to discover the v3 engineid and other parameters if that agent has never >been contacted. well in my case i was working with Westhawk Stack version 4_13, i have switched off the authentication and privacy flags in the context. also while initialising the context call TimeWindow.setSnmpEngineId(host, port, engineId), this will stop the discovery of engineId everytime before sending a packet > The bean class uses the default timeout when sending the Pdu >request for discovery. However, I had set a different retry_array on the >original Pdu that is causing the discovery to be sent in the first place. It >would make sense for the stack to use this retry array when sending the >discovery Pdu as well. Or at a minimum provide a way to change the default >retry array for v3 discovery. Perhaps there is another way to do this that >won't take so long that I am missing.. suggestions welcome. >Josh why dont you add the same retry array before v3 Discovery, i.e in UsmDiscoveryBean.java when you are creating an instance of DiscoveryPdu, just call method pdu.setRetryInterval(retry_array) and set the retries required there. Regards Gejo Joseph Flextronics Software Systems 18/1, Outer Ring Road Panathur Post, Bangalore "I would love to change the world, but no one would give me the source code" *********************** Aricent-Unclassified *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." From birgit at westhawk.co.uk Tue Jan 30 10:57:37 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Tue Jan 30 11:02:30 2007 Subject: [snmp] slow snmp v3 discovery timeout In-Reply-To: References: <005f01c74411$a43ad3c0$010010ac@JBERS2> Message-ID: <20070130105737.GA2350@westhawk.co.uk> On Tue, Jan 30, 2007 at 10:53:50AM +0530, Gejo.Thayil@aricent.com wrote: > >In working with snmpv3 contexts, I've found that sending a Pdu > >request to > >an > >agent is not there takes a long time to return ~19 seconds. When I > >looked > >into the code, it looks as though the v3 context is using a > >UsmDiscoveryBean > >to discover the v3 engineid and other parameters if that agent has > >never been contacted. > > > well in my case i was working with Westhawk Stack version 4_13, i have > switched off > the authentication and privacy flags in the context. also while > initialising the context > call TimeWindow.setSnmpEngineId(host, port, engineId), this will stop > the discovery of engineId every time before sending a packet That would certainly help if you know what the engineId is. However, Gejo, I would like to point out that the stack doesn't do recovery "every time before sending a packet". It only does it if the engineId is unknown, i.e. the first time and when discovery failed previously (Josh's problem). > >The bean class uses the default timeout when sending the Pdu > >request for discovery. However, I had set a different retry_array on > >the > >original Pdu that is causing the discovery to be sent in the first > >place. > >It > >would make sense for the stack to use this retry array when sending > >the > >discovery Pdu as well. Or at a minimum provide a way to change the > >default > >retry array for v3 discovery. Perhaps there is another way to do this > >that > >won't take so long that I am missing.. suggestions welcome. > > >Josh > > > why don't you add the same retry array before v3 Discovery, i.e in > UsmDiscoveryBean.java > when you are creating an instance of DiscoveryPdu, just call method > pdu.setRetryInterval(retry_array) > and set the retries required there. I'm not sure that is possible. pdu.setRetryInterval is not a static method: ( public void setRetryIntervals(int rinterval[]) ) and I don't see how you'd get your hands on the DiscoveryPdu object, created in UsmDiscoveryBean (that is created in SnmpContextv3Basis). I agree with Josh, parameters such as the retry_interval should be copied from Pdu to DiscoveryPdu via UsmDiscoveryBean. That probably means new methods - Pdu.getRetryIntervals() - UsmDiscoveryBean.setRetryIntervals() > Regards > Gejo Joseph Cheers, Birgit -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- tel.: +44 (0)161 237 0660 -- From jbers at bbn.com Tue Jan 30 11:27:54 2007 From: jbers at bbn.com (Josh Bers) Date: Tue Jan 30 16:30:15 2007 Subject: [snmp] slow snmp v3 discovery timeout In-Reply-To: <20070130105737.GA2350@westhawk.co.uk> Message-ID: <000601c7448b$9be6b700$010010ac@JBERS2> Birgit and Gejo, Thanks for the response. A questions: > > well in my case i was working with Westhawk Stack version > 4_13, i have > > switched off > > the authentication and privacy flags in the context. also while > > initialising the context > > call TimeWindow.setSnmpEngineId(host, port, engineId), this > will stop > > the discovery of engineId every time before sending a packet I am using 5_1 of the stack. I cannot turn off privacy or authentication (as they are required by my application), however, I can provide the engineid. In this configuration will it still attempt discovery before first contacting the agent? Josh > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit > Arkesteijn > Sent: Tuesday, January 30, 2007 5:58 AM > To: List for discussion of the Westhawk SNMP stack > Subject: Re: [snmp] slow snmp v3 discovery timeout > > > On Tue, Jan 30, 2007 at 10:53:50AM +0530, > Gejo.Thayil@aricent.com wrote: > > >In working with snmpv3 contexts, I've found that sending a Pdu > > >request to an > > >agent is not there takes a long time to return ~19 seconds. When I > > >looked > > >into the code, it looks as though the v3 context is using a > > >UsmDiscoveryBean > > >to discover the v3 engineid and other parameters if that agent has > > >never been contacted. > > > > > > well in my case i was working with Westhawk Stack version > 4_13, i have > > switched off > > the authentication and privacy flags in the context. also while > > initialising the context > > call TimeWindow.setSnmpEngineId(host, port, engineId), this > will stop > > the discovery of engineId every time before sending a packet > > > That would certainly help if you know what the engineId is. > However, Gejo, I would like to point out that the stack doesn't do > recovery "every time before sending a packet". > It only does it if the engineId is unknown, i.e. the first > time and when > discovery failed previously (Josh's problem). > > > > >The bean class uses the default timeout when sending the Pdu > > >request for discovery. However, I had set a different > retry_array on > > >the > > >original Pdu that is causing the discovery to be sent in the first > > >place. > > >It > > >would make sense for the stack to use this retry array when sending > > >the > > >discovery Pdu as well. Or at a minimum provide a way to change the > > >default > > >retry array for v3 discovery. Perhaps there is another way > to do this > > >that > > >won't take so long that I am missing.. suggestions welcome. > > > > >Josh > > > > > > why don't you add the same retry array before v3 Discovery, i.e in > > UsmDiscoveryBean.java > > when you are creating an instance of DiscoveryPdu, just call method > > pdu.setRetryInterval(retry_array) > > and set the retries required there. > > > I'm not sure that is possible. > pdu.setRetryInterval is not a static method: > ( public void setRetryIntervals(int rinterval[]) ) > > and I don't see how you'd get your hands on the DiscoveryPdu object, > created in UsmDiscoveryBean (that is created in SnmpContextv3Basis). > > I agree with Josh, parameters such as the retry_interval should be > copied from Pdu to DiscoveryPdu via UsmDiscoveryBean. > That probably means new methods > - Pdu.getRetryIntervals() > - UsmDiscoveryBean.setRetryIntervals() > > > > Regards > > Gejo Joseph > > > Cheers, Birgit > > -- > -- Birgit Arkesteijn, birgit@westhawk.co.uk, > -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK > -- tel.: +44 (0)161 237 0660 > -- > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > From birgit at westhawk.co.uk Tue Jan 30 17:06:51 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Tue Jan 30 17:11:55 2007 Subject: [snmp] slow snmp v3 discovery timeout In-Reply-To: <000601c7448b$9be6b700$010010ac@JBERS2> References: <20070130105737.GA2350@westhawk.co.uk> <000601c7448b$9be6b700$010010ac@JBERS2> Message-ID: <20070130170651.GI2350@westhawk.co.uk> Hi Josh, Yes, it would still attempt timeline discovery because of the authentication. :-( In order to fake that you'd have to make - uk.co.westhawk.snmp.stack.TimeWindowNode a public class and - make TimeWindow.setTimeLine public: protected uk.co.westhawk.snmp.stack.TimeWindowNode setTimeLine( java.lang.String snmpEngineId, uk.co.westhawk.snmp.stack.TimeWindowNode newNode) Cheers, Birgit On Tue, Jan 30, 2007 at 11:27:54AM -0500, Josh Bers wrote: > Birgit and Gejo, > > Thanks for the response. A questions: > > > > well in my case i was working with Westhawk Stack version > > > 4_13, i have > > > switched off > > > the authentication and privacy flags in the context. also while > > > initialising the context > > > call TimeWindow.setSnmpEngineId(host, port, engineId), this > > > will stop > > > the discovery of engineId every time before sending a packet > > I am using 5_1 of the stack. I cannot turn off privacy or > authentication (as > they are required by my application), however, I can provide the > engineid. > In this configuration will it still attempt discovery before first > contacting the agent? > > Josh -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- tel.: +44 (0)161 237 0660 -- From achandler at visionael.com Tue Jan 30 15:44:28 2007 From: achandler at visionael.com (Andy Chandler) Date: Tue Jan 30 21:47:05 2007 Subject: [snmp] Possible flaw in transmitter? Message-ID: <014d01c744b7$d6ee16a0$83b328c0@visionael.com> I'm tracking an elusive nullpointer in a multi-threaded app that does quite a bit of snmp. I may have nailed down my original problem but I also saw this snippet of code in the transmitter and I'm hoping someone can put me at ease that the nullpointer couldn't come from here: /** * This method is the counterpart of sit(). * * The Pdu will call this method when it is sent. * This method will notify itself and in the end it is transmitted * in run. * * @see #sit() * @see #run() * @see Pdu#send */ synchronized void stand() { notifyAll(); } /** * It may be sleeping (as opposed to wait()ing * so send it a kick. */ void interruptMe() { // unsafe ? me.interrupt(); } void destroy() { me = null; pdu=null; stand(); } When context.destroy() is called it calls destroy on the transmitters ( by actually calling the freetransmitters method). My thought is this: If a trnasmitter is "sit" and a destroy comes in, it will set "me = null". What if a latent host reponds at that moment? It would call pdufillin which in turn would call interuptMe() - however since "me" is null courtesy of the non synchronized destroy then you would get a nullpointer from "me.interrupt()" I know it sounds a long shot but when you are running 99 major threads, each running 3 discovery subthreads across 65k - 16Million addresses the statistically improbable can happen. If I'm in any way correct about this could the following changes alleviate the risk? destroy calls interruptMe() first and THEN sets me = null ? Synchronizing destroy in the past led to some stack deadlocks so I'm avoiding that as a suggestion. From birgit at westhawk.co.uk Wed Jan 31 13:41:39 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Jan 31 13:46:43 2007 Subject: [snmp] Stack as Agent (was: deadlock when destroying a context) In-Reply-To: <5FD52D0FD7C327449FD02EBBB79B331E042BCD@exchange01.ziplip.net> References: <200701261425.l0QEPuh18949@snmp.westhawk.co.uk> <5FD52D0FD7C327449FD02EBBB79B331E042BCD@exchange01.ziplip.net> Message-ID: <20070131134139.GD5814@westhawk.co.uk> Hi Stephen, > While building an agent, I needed an AsnObjectId comparator > or have AsnObjectId implement Comparable. I built an AsnObjectId > comparator, which made get next requests easier to fulfill. > Any thoughts about providing this in the stack? Sounds like a good idea! If you're willing to provide this piece of code, we'll certainly look at it and add it to the stack if we're happy with it. > Any chance of providing a better example of an agent with get or get > next response? > The trap example just sends or receives, and I had to combine the two > to get a working agent. The problem is that the stack has no architecture that helps you to gather the response data. (The main reason is that we don't want to build in MIB knowledge (or a MIB parser)). Therefor it isn't easy to come up with a good (or extensive) example. The best examples are in examplevX/ReceiveTrap.requestPduReceived() (where X = (2c or 3)) This example - tests for an incoming GetRequest(sysContact0) - responds with my name and email address Let me know what example you'd like to have and I'll see what I can do. > My biggest wish would be for an agent that responds to Sun's JVM MIB > and is extendable, as the one included in the 1.5 JVM is not > extendable. Unfortunately I'm not up to speed with Sun's 1.5 JVM MIB (sorry). Allegedly the source code is available? So maybe we could wrap some code around it. However, I'm not sure I've got time in the near future to have a look. Don't let that prevent you to send us your thoughts. Feedback, ideas and suggestions are always welcome! > Stephen Chen > Senior Software Engineer > ZipLip, Inc. > schen@ziplip.net Cheers, Birgit -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- tel.: +44 (0)161 237 0660 --