[SNMP4J] snmp4j timeouts even when response is received

[Frank Fock]

Yes, if you have only a single Snmp instance, you do not need more than one
transport mapping per transport.


Am 24.07.2012 20:33, schrieb Prema Upot:
> 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:fock at agentpp.com]
> Sent: Tuesday, July 24, 2012 11:52 AM
> To: Prema Upot
> Cc: snmp4j at agentpp.org
> 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:fock at agentpp.com]
>> 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: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org]
>>> On Behalf Of Frank Fock
>>> Sent: Monday, July 23, 2012 5:16 PM
>>> To: snmp4j at agentpp.org
>>> 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
>>>> SNMP4J at agentpp.org
>>>> 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
>

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231