We close the snmp object after each request and the application is multi threaded. I will change the application to use a Snmp singleton as you suggested. Should the TransportMapping class be also a singleton ?
Thanks, -----Original Message----- From: Frank Fock [mailto:[email protected]] Sent: Tuesday, July 24, 2012 11:52 AM To: Prema Upot Cc: [email protected] Subject: Re: [SNMP4J] snmp4j timeouts even when response is received Creating a new Snmp object for each request might cause this behavior. Do you close it? Is the application multi-threaded? You should use only one Snmp instance, opening closing it for each request has a huge overhead! Best regards, Frank Am 24.07.2012 15:22, schrieb Prema Upot: > Yes, for sure we use a different PDU every time. Our snmp4j wrapper code is > very similar to console.SnmpRequest. Everytime we create a new Snmp object, a > new Target and a new PDU. Most of the gets go through fine but we do see > these timeouts around 10 times in an hour (out of approximately 3000 snmp > get/set requests/hour). > The logs we see are like this, > > 2012-07-22 05:38:50,088 DEBUG [ pool-1-thread-4 ] Running pending > sync request with handle PduHandle[1553939504] and retry count left 0 > 2012-07-22 05:38:50,088 DEBUG [ pool-1-thread-4 ] Sending message > to 192.168.30.26/161 with length 63: 30 3d 02 01 01 04 06 70 75 62 6c 69 63 > a0 30 02 04 5c 9f 3c 30 02 01 00 02 01 00 30 22 30 12 06 0e 2b 06 01 04 01 81 > bb 56 04 05 01 13 00 00 05 00 30 0c 06 08 2b 06 01 02 01 01 05 00 05 00 > ... > 2012-07-22 05:38:50,090 DEBUG [ nsportMapping_192.168.30.109/0 ] > Received message from /192.168.30.26/161 with length 156: 30 82 00 98 > 02 01 01 04 06 70 75 62 6c 69 63 a2 82 00 89 02 04 5c 9f 3c 30 02 01 > 00 02 01 00 30 82 00 79 30 82 00 58 06 0e 2b 06 01 04 01 81 bb 56 04 > 05 01 13 00 00 04 46 50 56 20 30 2e 30 2e 32 3b 42 4c 20 31 2e 34 2e > 31 30 3b 53 57 20 33 2e 31 30 2e 31 30 33 35 3b 48 57 20 33 2e 32 2e > 33 3b 43 43 54 20 30 2e 30 2e 34 3b 52 45 4c 20 34 2e 34 3b 4d 4d 20 > 4d 47 54 2d 32 31 35 30 30 82 00 19 06 08 2b 06 01 02 01 01 05 00 04 > 0d 31 39 32 2e 31 36 38 2e 33 30 2e 32 36 > 2012-07-22 05:38:50,090 DEBUG [ nsportMapping_192.168.30.109/0 ] Looking up > pending request with handle PduHandle[1553939504] > 2012-07-22 05:38:50,090 WARN [ nsportMapping_192.168.30.109/0 ] Received > response that cannot be matched to any outstanding request, > address=192.168.30.26/161, requestID=1553939504 > > As you can see the response is received within 2 milliseconds. > > Thanks, > > -----Original Message----- > From: Frank Fock [mailto:[email protected]] > Sent: Monday, July 23, 2012 5:19 PM > To: Prema Upot > Subject: Re: [SNMP4J] snmp4j timeouts even when response is received > > Are you sure? Do you reuse the PDU object after you send the request? > > Am 23.07.2012 23:16, schrieb Prema Upot: >> Yes it does have the same ID. We use synchronous get. >> >> Thanks, >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Frank Fock >> Sent: Monday, July 23, 2012 5:16 PM >> To: [email protected] >> Subject: Re: [SNMP4J] snmp4j timeouts even when response is received >> >> Hi, >> >> Does the response has the same request ID as the request? >> >> Best regards, >> Frank >> >> Am 23.07.2012 22:46, schrieb Prema Upot: >>> Hi, >>> >>> We see timeouts in snmp4j intermittently for snmp get requests even though >>> the response is received well within the timeout period. When debug is >>> turned on, I see messages like "Received response that cannot be matched to >>> any outstanding request, address...". The timeout set is 8 seconds and the >>> actual response is received within a few milliseconds (as seen in snmp4j >>> logs). The snmp4j version is 1.11. Has anyone seen this problem ? >>> >>> Thanks, >>> >>> _______________________________________________ >>> SNMP4J mailing list >>> [email protected] >>> http://lists.agentpp.org/mailman/listinfo/snmp4j -- --- AGENT++ Maximilian-Kolbe-Str. 10 73257 Koengen, Germany https://agentpp.com Phone: +49 7024 8688230 Fax: +49 7024 8688231 _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
