Hi Jones, Well described observation. Yes, SNMP4J 1.x behaves that way. I have checked the SNMPv3 RFC 3412 and I think it allows to optimize the behavior to allow receiving a response to a former retry (or original request) after the next retry has been send out.
I will now implement that optimization for SNMP4J 2.0. Depending on the implementation complexity, I will also provide a back-port for the 1.x branch. Best regards, Frank On 19.07.2011 14:25, jones vinu wrote: > Hi Frank, > > We have a case in snmpv3 request where we receive a response for the first > request after we have send the first retries. Our timeout for the first > request is 8 sec we receive the response after 8 sec for this request hence > we discard this message(msgID could not be found in the log). Is this an > excepted behavior or the response after the first retries still be processed? > > Debug log > > Sending first request > 2011-07-18 16:39:21,879 DEBUG [186]-[org.snmp4j.mp.MPv3] Adding cache entry: > StateReference[msgID=1307970872,pduHandle=PduHandle[1225850246],securityEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,securityModel=org.snmp4j.security.USM@6dff17b9,securityName=gpon123,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,contextName=nt] > > Sending first retries after 8 sec > > 2011-07-18 16:39:29,885 DEBUG [Timer-17]-[org.snmp4j.mp.MPv3] Adding cache > entry: > StateReference[msgID=1307970884,pduHandle=PduHandle[1225850246],securityEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,securityModel=org.snmp4j.security.USM@6dff17b9,securityName=gpon123,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,contextName=nt] > 2011-07-18 16:39:29,994 DEBUG [Timer-17]-[org.snmp4j.security.USM] > getUser(engineID=80:00:02:7d:03:00:0e:86:1c:12:17, securityName=gpon123) > > Response for first request. We get the response after the second retry so the > cache is overridden with the first retry msg. PDUHandle is the key in the map > and the retries use the same PDU handle for all retries. This explains the > msgID could not be found in the cache and the NoError warnings. > > 2011-07-18 16:39:31,560 DEBUG > [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.mp.MPv3] SNMPv3 > header decoded: msgId=1307970872, msgMaxSize=65535, msgFlags=07, secModel=3 > 2011-07-18 16:39:31,561 DEBUG > [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.security.USM] > getUser(engineID=80:00:02:7d:03:00:0e:86:1c:12:17, securityName=gpon123) > 2011-07-18 16:39:31,562 DEBUG > [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.mp.MPv3] RFC3412 > ยง7.2.10 - Received PDU (msgID=1307970872) is a response or internal class > message, but cached information for the msgID could not be found > 2011-07-18 16:39:31,562 WARN > [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.MessageDispatcherImpl] > noError > > Thanks > Jones > _______________________________________________ > SNMP4J mailing list > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
