From daniel at readytechnology.co.uk Sun Oct 7 12:47:14 2007 From: daniel at readytechnology.co.uk (Daniel Pocock) Date: Sun Oct 7 13:36:52 2007 Subject: [snmp] Westhawk SNMP in JBoss or J2EE servers? Message-ID: <4708AB22.4030101@readytechnology.co.uk> Hi, I'm concerned that it is difficult to use the Westhawk SNMP stack in JBoss and other J2EE servers. After sending many SNMP get requests, JBoss becomes slow. J2EE/EJB specifications prohibit thread creation. I believe the threads created by the stack are causing the issues in JBoss. The `nothread' notes provide a solution for sending traps, but this is not a complete solution. J2EE offers solutions such as Timer beans, Connectors and MBeans that could be used to achieve the functionality provided by threading, in an EJB compliant manner. Have these issues already been considered? Is anyone already running the stack successfully in JBoss? Is anyone already working on a solution to this problem? Regards, Daniel From thp at westhawk.co.uk Sun Oct 7 14:58:24 2007 From: thp at westhawk.co.uk (Tim H. Panton) Date: Sun Oct 7 13:59:48 2007 Subject: [snmp] Westhawk SNMP in JBoss or J2EE servers? In-Reply-To: <4708AB22.4030101@readytechnology.co.uk> Message-ID: <12975452.48801191761904729.JavaMail.root@zimbra> I don't think it is the threading that would be a problem per-se. We need (at minimum) one datagram socket listening on port 161, and reasonable degree of certainty that datagram will be received and queued. I have no clue how you can do that in J2EE. Tim. ----- Original Message ----- From: "Daniel Pocock" To: snmp@snmp.westhawk.co.uk Sent: Sunday, October 7, 2007 10:47:14 AM (GMT) Europe/London Subject: [snmp] Westhawk SNMP in JBoss or J2EE servers? Hi, I'm concerned that it is difficult to use the Westhawk SNMP stack in JBoss and other J2EE servers. After sending many SNMP get requests, JBoss becomes slow. J2EE/EJB specifications prohibit thread creation. I believe the threads created by the stack are causing the issues in JBoss. The `nothread' notes provide a solution for sending traps, but this is not a complete solution. J2EE offers solutions such as Timer beans, Connectors and MBeans that could be used to achieve the functionality provided by threading, in an EJB compliant manner. Have these issues already been considered? Is anyone already running the stack successfully in JBoss? Is anyone already working on a solution to this problem? Regards, Daniel _______________________________________________ snmp mailing list snmp@snmp.westhawk.co.uk http://snmp.westhawk.co.uk/mailman/listinfo/snmp From birgit at westhawk.co.uk Wed Oct 10 12:02:06 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Oct 10 11:03:22 2007 Subject: [snmp] SNMP v3 discovery bug in 5.1 In-Reply-To: References: <004c01c7f6e5$acf6af20$010010ac@JBERS2> <46EE7BED.7020303@westhawk.co.uk> <46EE8CCB.8010606@westhawk.co.uk> <46EEB348.5040309@bbn.com> <46EFDE2A.60701@westhawk.co.uk> Message-ID: <470CA31E.2090302@westhawk.co.uk> Hi Josh, Sorry for my late reply, I was on holiday for two weeks. I don't know where the 10s comes from. Discovery is only done (if needed) when adding the pdu to the v3 context. First the engineid is discovered (unless already known), then the timeline is discovered (only if the engine id is known AND the timeline isn't known yet). Cheers, Birgit On 28/09/07 22:45, Josh Bers wrote: > Birgit, > > I have confirmed the success of the fix. One strange behavior: On failure > when disconnected, it takes about 10 seconds for the discovery timeout to > happen even though my retry array is [750, 1500, 2250]. Does discovery try > twice per retry? > > We would like to get a new release of the stack with this fix in place as > it makes SNMPv3 usable for our application. Can you give me an estimate > for when the next release will be available? > > Regards, > > Josh -- -- Birgit Arkesteijn, birgit@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 -- From jbers at bbn.com Thu Oct 11 15:29:12 2007 From: jbers at bbn.com (Josh Bers) Date: Thu Oct 11 19:29:59 2007 Subject: [snmp] SNMP v3 discovery bug in 5.1 In-Reply-To: <470CA31E.2090302@westhawk.co.uk> Message-ID: <001901c80c34$a22b0460$010010ac@JBERS2> Birgit, I think in your response you may have answered the question: since discovery involves potentially two PDU's (timeline & engineid) that would result in 2x the timeout :-) Make sense? Josh > -----Original Message----- > From: Birgit Arkesteijn [mailto:birgit@westhawk.co.uk] > Sent: Wednesday, October 10, 2007 6:02 AM > To: Josh Bers > Cc: Jonathan Tung; 'List for discussion of the Westhawk SNMP > stack'; 'Stephane Blais' > Subject: Re: [snmp] SNMP v3 discovery bug in 5.1 > > > Hi Josh, > > Sorry for my late reply, I was on holiday for two weeks. > > I don't know where the 10s comes from. > Discovery is only done (if needed) when adding the pdu to the > v3 context. First the engineid is discovered (unless already > known), then the > timeline is discovered (only if the engine id is known AND > the timeline > isn't known yet). > > Cheers, Birgit > > > On 28/09/07 22:45, Josh Bers wrote: > > Birgit, > > > > I have confirmed the success of the fix. One strange behavior: On > > failure when disconnected, it takes about 10 seconds for > the discovery > > timeout to happen even though my retry array is [750, 1500, 2250]. > > Does discovery try twice per retry? > > > > We would like to get a new release of the stack with this > fix in place > > as it makes SNMPv3 usable for our application. Can you give me an > > estimate for when the next release will be available? > > > > Regards, > > > > Josh > > > -- > -- Birgit Arkesteijn, birgit@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 > -- > From birgit at westhawk.co.uk Mon Oct 15 11:15:44 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Mon Oct 15 10:17:00 2007 Subject: [snmp] SNMP v3 discovery bug in 5.1 In-Reply-To: <001901c80c34$a22b0460$010010ac@JBERS2> References: <001901c80c34$a22b0460$010010ac@JBERS2> Message-ID: <47132FC0.6080104@westhawk.co.uk> Hi Josh, I'm still not too sure. Timeline is only discovered when the engineid was successfully discovered, so when timing out on engineid, it shouldn't go for timeline. Birgit On 11/10/07 19:29, Josh Bers wrote: > Birgit, > > I think in your response you may have answered the question: since discovery > involves potentially two PDU's (timeline & engineid) that would result in 2x > the timeout :-) Make sense? > > Josh > >> -----Original Message----- >> From: Birgit Arkesteijn [mailto:birgit@westhawk.co.uk] >> Sent: Wednesday, October 10, 2007 6:02 AM >> To: Josh Bers >> Cc: Jonathan Tung; 'List for discussion of the Westhawk SNMP >> stack'; 'Stephane Blais' >> Subject: Re: [snmp] SNMP v3 discovery bug in 5.1 >> >> >> Hi Josh, >> >> Sorry for my late reply, I was on holiday for two weeks. >> >> I don't know where the 10s comes from. >> Discovery is only done (if needed) when adding the pdu to the >> v3 context. First the engineid is discovered (unless already >> known), then the >> timeline is discovered (only if the engine id is known AND >> the timeline >> isn't known yet). >> >> Cheers, Birgit >> >> >> On 28/09/07 22:45, Josh Bers wrote: >>> Birgit, >>> >>> I have confirmed the success of the fix. One strange behavior: On >>> failure when disconnected, it takes about 10 seconds for >> the discovery >>> timeout to happen even though my retry array is [750, 1500, 2250]. >>> Does discovery try twice per retry? >>> >>> Regards, >>> >>> Josh -- -- Birgit Arkesteijn, birgit@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 -- From vijay_gholap at datamatics.com Wed Oct 24 15:54:07 2007 From: vijay_gholap at datamatics.com (Vijay Gholap) Date: Wed Oct 24 10:23:44 2007 Subject: [snmp] SNMP trap problem (thread count) Message-ID: <000801c8161f$a1871180$0c21a8c0@4259Vijay> Hi, I have an application in which i have implemented SNMP Trap sending functionality. My problem is that, i am able to send snmp trap(version 1/2) without any problem, but my applications thread count getting incremented on every send. So please help me to reduce this. Bellow is code snap of my appliaction... try { SnmpContext context = new SnmpContext(host, port, bindAddr, socketType); context.setCommunity(community); TrapPduv1 pdu = new TrapPduv1(context); pdu.setIpAddress(InetAddress.getLocalHost().getAddress()); pdu.setEnterprise("1.3.6.1.4.1.12.1"); pdu.setSpecificTrap(6); pdu.setTimeTicks(10000); pdu.addOid(sysUpTime, new AsnUnsInteger(5)); pdu.addOid(snmpTrapOID, new AsnObjectId("1.3.6.1.4.1.12.1")); pdu.send(); } catch (java.io.IOException exc) { System.out.println("IOException " + exc.getMessage()); } catch (uk.co.westhawk.snmp.stack.PduException exc) { System.out.println("PduException " + exc.getMessage()); } Regards, Vijay Gholap. Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message. From birgit at westhawk.co.uk Wed Oct 24 11:39:16 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Oct 24 10:41:03 2007 Subject: [snmp] SNMP trap problem (thread count) In-Reply-To: <000801c8161f$a1871180$0c21a8c0@4259Vijay> References: <000801c8161f$a1871180$0c21a8c0@4259Vijay> Message-ID: <471F12C4.8040404@westhawk.co.uk> Hi Vijay, First of all, try using the SnmpContextPool class. Secondly, the thread will only be destroyed when you destroy the context. That isn't so straightforward with traps, because send() isn't synchronised, so you have to give the context a bit of time to actually send the PDU before you can destroy it. Try a few second sleep and then destroy the context. Cheers, Birgit Vijay Gholap wrote: > Hi, > > I have an application in which i have implemented SNMP Trap sending > functionality. My problem is that, i am able to send snmp trap(version 1/2) > without any problem, but my applications thread count getting incremented on > every send. So please help me to reduce this. Bellow is code snap of my > application... > > try { > > > SnmpContext context = new SnmpContext(host, port, bindAddr, socketType); > context.setCommunity(community); > > TrapPduv1 pdu = new TrapPduv1(context); > pdu.setIpAddress(InetAddress.getLocalHost().getAddress()); > pdu.setEnterprise("1.3.6.1.4.1.12.1"); > pdu.setSpecificTrap(6); > pdu.setTimeTicks(10000); > > > pdu.addOid(sysUpTime, new AsnUnsInteger(5)); > pdu.addOid(snmpTrapOID, new AsnObjectId("1.3.6.1.4.1.12.1")); > pdu.send(); > > } catch (java.io.IOException exc) { > System.out.println("IOException " + exc.getMessage()); > } catch (uk.co.westhawk.snmp.stack.PduException exc) { > System.out.println("PduException " + exc.getMessage()); > } > > > > Regards, > > Vijay Gholap. From vijay_gholap at datamatics.com Wed Oct 24 17:57:37 2007 From: vijay_gholap at datamatics.com (Vijay Gholap) Date: Wed Oct 24 12:28:46 2007 Subject: [snmp] SNMP Trap send problem Message-ID: <000c01c81630$e1de6970$0c21a8c0@4259Vijay> Hi, I am using westhawk snmp stak(5.1) to send a trap(snmp v1). In my application using snmpcontext class everything works fine, but if i changed SnmpContext class to SnmpContextPool, its give me following error.. Exception in thread "main" java.lang.ClassCastException: uk.co.westhawk.snmp.stack.SnmpContextPool at uk.co.westhawk.snmp.stack.TrapPduv1.send(TrapPduv1.java:225) at com.exfo.ems.nbi.client.SNMPClientV1.sendTrap(SNMPClientV1.java:65) at com.exfo.ems.nbi.client.SNMPFactory.main(SNMPFactory.java:29) Please help me out... Regards, Vijay Gholap. Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message. From birgit at westhawk.co.uk Wed Oct 24 13:50:19 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Oct 24 12:51:36 2007 Subject: [snmp] SNMP Trap send problem In-Reply-To: <000c01c81630$e1de6970$0c21a8c0@4259Vijay> References: <000c01c81630$e1de6970$0c21a8c0@4259Vijay> Message-ID: <471F317B.5080906@westhawk.co.uk> Hi Vijay, That's an error in TrapPduv1, sorry. It seems you're have to get back to SnmpContext and destroy the context after the trap has been send. Just do a sleep of a few seconds, see uk.co.westhawk.examplev1.SendTrap Sorry about that. Cheers, Birgit On 24/10/07 12:27, Vijay Gholap wrote: > Hi, > > I am using westhawk snmp stak(5.1) to send a trap(snmp v1). In my > application using snmpcontext class everything works fine, but if i changed > SnmpContext class to SnmpContextPool, its give me following error.. > > Exception in thread "main" java.lang.ClassCastException: > uk.co.westhawk.snmp.stack.SnmpContextPool > at uk.co.westhawk.snmp.stack.TrapPduv1.send(TrapPduv1.java:225) > at com.exfo.ems.nbi.client.SNMPClientV1.sendTrap(SNMPClientV1.java:65) > at com.exfo.ems.nbi.client.SNMPFactory.main(SNMPFactory.java:29) > > Please help me out... > > Regards, > Vijay Gholap. > > Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message. > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp -- -- Birgit Arkesteijn, birgit@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 -- From vijay_gholap at datamatics.com Thu Oct 25 18:18:13 2007 From: vijay_gholap at datamatics.com (Vijay Gholap) Date: Thu Oct 25 12:53:28 2007 Subject: [snmp] SNMP trap send Message-ID: <000001c816fc$ed3cbed0$0c21a8c0@4259Vijay> Hi, I am using westhawk snmp stack 5.1 in my application to send a trap. I have created a TrapPduv2 pdu and added the require variable bindings in it. After sending this pdu to onother application(Trap receiver) its giving error. But after adding another following to value in to varaiable binding to pdu , its working fine. 1. sysUpTime(1.3.6.1.2.1.1.3.0): AsnUnsInteger(5) 2. snmpTrapOID(1.3.6.1.6.3.1.1.4.3.0): AsnObjectId("1.3.6.1.4.1.6718.1") Please let me what mistake i am doing. Or should i compulsory required to add above values in TrapPdu2 varbindings?. Regards, Vijay Gholap. Disclaimer: The information contained in this e-mail and attachments if any are privileged and confidential and are intended for the individual(s) or entity(ies) named in this e-mail. If the reader or recipient is not the intended recipient, or employee or agent responsible for delivering to the intended recipient, you are hereby notified that dissemination, distribution or copying of this communication or attachments thereof is strictly prohibited. IF YOU RECEIVE this communication in error, please immediately notify the sender and return the original message. From birgit at westhawk.co.uk Thu Oct 25 15:00:33 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Thu Oct 25 14:01:51 2007 Subject: [snmp] SNMP trap send In-Reply-To: <000001c816fc$ed3cbed0$0c21a8c0@4259Vijay> References: <000001c816fc$ed3cbed0$0c21a8c0@4259Vijay> Message-ID: <47209371.70108@westhawk.co.uk> Hi Vijay, Yes, you have to include those two varbinds to the varbind list of TrapPduv2. If you read the javadoc for uk.co.westhawk.snmp.stack.TrapPduv2, it says: The variable bindings list contains the following pairs of object names and values: * sysUpTime.0 (SNMPv2-MIB) * snmpTrapOID.0: part of the trap group in the SNMPv2 MIB (SNMPv2-MIB) Cheers, Birgit On 25/10/07 12:48, Vijay Gholap wrote: > Hi, > > I am using westhawk snmp stack 5.1 in my application to send a trap. I > have created a TrapPduv2 pdu and added the require variable bindings in it. > After sending this pdu to another application(Trap receiver) its giving > error. But after adding another following to value in to variable binding > to pdu , its working fine. > 1. sysUpTime(1.3.6.1.2.1.1.3.0): AsnUnsInteger(5) > 2. snmpTrapOID(1.3.6.1.6.3.1.1.4.3.0): AsnObjectId("1.3.6.1.4.1.6718.1") > > Please let me what mistake i am doing. Or should i compulsory required to > add above values in TrapPdu2 varbindings?. > > > Regards, > Vijay Gholap. -- -- Birgit Arkesteijn, birgit@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 -- From vijay_gholap at datamatics.com Mon Oct 29 17:17:41 2007 From: vijay_gholap at datamatics.com (Vijay Gholap) Date: Mon Oct 29 11:42:40 2007 Subject: [snmp] Problem: SNMP application with different versions. Message-ID: <000001c81a21$83b43f10$0c21a8c0@4259Vijay> Hi all, I have a list (ArrayList) contains the snmp paramaters. I have created one factory class which will return the reference of passed version. i.e. if i passed version 1, it will return me reference of class which has a logic of sending trap of version 1. I have iterated list and sended the trap for the list data. for(i=0;i References: <000001c81a21$83b43f10$0c21a8c0@4259Vijay> Message-ID: <4725CE75.6060508@westhawk.co.uk> Hi Vijay, Your snippet of code seems fine. Also, since you manage to send v1 and v2 traps, it seems that the implementation of SNMPClienV1 and SNMPClientV2 is fine. The fact that the first item in the list determines what goes for the life of your application, indicates (to me) that the problem is within SNMPFactory.getSNMPFactory(list.get(i)); I would try printing out - list.get(i) and - snmpcilent to confirm my suspicion and take a closer look at SNMPFactory.getSNMPFactory(). Cheers, Birgit On 29/10/07 11:47, Vijay Gholap wrote: > > Hi all, > > I have a list (ArrayList) contains the snmp parameters. I have created > one factory class which will return the reference of passed version. i.e. if > i passed version 1, it will return me reference of class which has a logic > of sending trap of version 1. I have iterated list and sent the trap for > the list data. > > for(i=0;i ISNMPClient snmpcilent =SNMPFactory.getSNMPFactory(list.get(i)); > snmpcilent.setManagerConfig(manager); > snmpcilent.sendTrap(pdu); > } > > ISNMPClient is interface implemented by two classes... > 1. SNMPClienV1 > 2. SNMPClientV2 > > which has a logic of sending snmp v1 and v2 trap respectively. > SNMPFactory returns the reference of one of above class... i.e if i pass > version=1; it will give me reference of SNMPClientV1 class. > > My problem is.... > > If my list contains the first data is version1... it sends the trap only for > version 1.. but not for version2. > and if my list contains first snmp version 2 data.. then its sends only snmp > 2 related trap. > > > Suppose if my list is like this... > list[1,1,2,1,2] .... i.e contains the snmp version of which i want to send a > trap. > Then, > My application send the trap of SNMPClientV1 only but not SNMPClientV2.. > If my list is like this... > list[2,1,2,1,2] ... > Then, > My application send the trap of SNMPClientV2 only but not SNMPClientV1.. > > As per my observation.. application sending trap for the version which is > the first version in list. > > > So please help me out .... > > Thanks, > Vijay Gholap. -- -- Birgit Arkesteijn, birgit@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 -- From sharath at alcatel-lucent.com Wed Oct 31 17:48:33 2007 From: sharath at alcatel-lucent.com (K, Sharath (Sharath)) Date: Wed Oct 31 14:20:45 2007 Subject: [snmp] Need way to re-discover timeline info to recover from usmStatsNotInTimeWindows Message-ID: Hello, We are using the westhawk stack version 5.0 in one of our management applications, which connect to SNMPv3 based network elements (NEs). We create the NE on the manager application and use the stack to heartbeat (GET a couple of SNMP scalar attributes) the NE every 1 minute. Once the NE is created on the manager, a new SnmpContext is also created and cached till the NE is deleted from the application. Upon deleting the NE, the context is also destroyed. We are facing a situation where-in the engineId, engineBoots and engineTime are in synch between the manager and the NE (authoritative engine), up until some commands are executed on the NE which update the snmp configuration. When these commands are executed on the NE, the engineTime is being reset to 0 on the NE, but the engineBoots remains the same. When the manager now sends out the next heartbeat SNMP GET request, we get a usmStatsNotInTimeWindows error since the local engineTime is greater than the NE's engineTime. The only way to recover from this situation is to restart the manager application (and hence the stack), which we cannot afford to do. I initially thought that once the context corresponding to the NE was destroyed and re-created, it would re-discover by sending engineBoots=0 and engineTime=0, but the stack still retains the old values of engineBoots and engineTime even if there is no corresponding context. I tried to do a forced discovery whenever usmStatsNotInTimeWindows exception was detected, but this does not update the timeline info. I see from TimeWindow.updateTimeWindow(), that timeline is updated only if (bootsA > bootsL || (bootsA == bootsL && timeA > latestL)) But in our case, bootsA == bootsL, but timeA < latestL. Is there a way to recover from this situation? Can you provide some public methods in TimeWindow.java to clear the engineId and/or engineBoots and engineTime entries from the "hostLookup" and "engineLookup" Hashtables? This will enable us to re-initate a discovery and recover from this situation. Or How about removing the corresponding entries in the hostLookup and engineLookup Hashtables upon a context getting destroyed? Because once the entries are stored for a given ip:port combination, they remain for the lifetime of the stack, even if there is no context associated with the given ip and port. Doesn't this seem wasteful? Any other suggestions to overcome this situation will be helpful. Thanks, Sharath From birgit at westhawk.co.uk Wed Oct 31 14:44:41 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Oct 31 14:46:05 2007 Subject: [snmp] Need way to re-discover timeline info to recover from usmStatsNotInTimeWindows In-Reply-To: References: Message-ID: <472894D9.20702@westhawk.co.uk> Hi Sharath, We added: public void TimeWindow.clearTimeWindow(java.lang.String snmpEngineId) but haven't (yet) turned that change into a public release. You can download the code, however, from SourceForge. http://sourceforge.net/projects/westhawksnmp/ I don't think keeping the SNMPv3 discovery details when a context is destroyed is wasteful. It saves (potential) two discovery PDUs when a new context is created and a new request PDU sent. We're not talking about bulk data either, so it won't take up that much space. Cheers, Birgit On 31/10/07 12:18, K, Sharath (Sharath) wrote: > Hello, > We are using the westhawk stack version 5.0 in one of our management > applications, which connect to SNMPv3 based network elements (NEs). > > We create the NE on the manager application and use the stack to > heartbeat (GET a couple of SNMP scalar attributes) the NE every 1 > minute. > Once the NE is created on the manager, a new SnmpContext is also created > and cached till the NE is deleted from the application. Upon deleting > the NE, the context is also destroyed. > We are facing a situation where-in the engineId, engineBoots and > engineTime are in synch between the manager and the NE (authoritative > engine), up until some commands are executed on the NE which update the > snmp configuration. When these commands are executed on the NE, the > engineTime is being reset to 0 on the NE, but the engineBoots remains > the same. > When the manager now sends out the next heartbeat SNMP GET request, we > get a usmStatsNotInTimeWindows error since the local engineTime is > greater than the NE's engineTime. > The only way to recover from this situation is to restart the manager > application (and hence the stack), which we cannot afford to do. I > initially thought that once the context corresponding to the NE was > destroyed and re-created, it would re-discover by sending engineBoots=0 > and engineTime=0, but the stack still retains the old values of > engineBoots and engineTime even if there is no corresponding context. > > I tried to do a forced discovery whenever usmStatsNotInTimeWindows > exception was detected, but this does not update the timeline info. > I see from TimeWindow.updateTimeWindow(), that timeline is updated only > if (bootsA > bootsL || > (bootsA == bootsL && timeA > latestL)) > > But in our case, bootsA == bootsL, but timeA < latestL. > > Is there a way to recover from this situation? > > Can you provide some public methods in TimeWindow.java to clear the > engineId and/or engineBoots and engineTime entries from the "hostLookup" > and "engineLookup" Hashtables? > This will enable us to re-initate a discovery and recover from this > situation. > > Or > > How about removing the corresponding entries in the hostLookup and > engineLookup Hashtables upon a context getting destroyed? > Because once the entries are stored for a given ip:port combination, > they remain for the lifetime of the stack, even if there is no context > associated with the given ip and port. Doesn't this seem wasteful? > > Any other suggestions to overcome this situation will be helpful. > > Thanks, > Sharath > > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp -- -- Birgit Arkesteijn, birgit@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 --