[SNMP4J] Fw: Re: Thread count leads to SNMP response timeouts in snmp4j version 1.7.1

Frank Fock fock at agentpp.com
Fri Jan 28 22:13:57 CET 2011


Hi,

It seems that the problem is not caused by the
SNMP4J API, but in the application.

Best regards,
Frank


On 28.01.2011 21:51, loaner45244 at mypacks.net wrote:
>
> -----Forwarded Message-----
>> Subject: Re: [SNMP4J] Thread count leads to SNMP response timeouts in snmp4j version 1.7.1
>>
>> These are our internal threads (ThreadPool) that spawn off and
>> manage snmp traffic to approximately 1000 peers. The problem is
>> that as we add additional threads, the org.snmp4j.Snmp object's
>> ResponseListener callback begins to timeout.
>>
>> I did not follow the memory question - the machine has several
>> Gigs of memory so that should not be an issue but is there any
>> particular thread based (minimum) limit that I must check?
>>
>> Thanks,
>>
>> HA
>>
>>
>> -----Original Message-----
>>> From: Frank Fock<fock at agentpp.com>
>>> Sent: Jan 25, 2011 5:08 PM
>>> To: snmp4j at agentpp.org
>>> Subject: Re: [SNMP4J] Thread count leads to SNMP response timeouts in snmp4j version 1.7.1
>>>
>>> Hi,
>>>
>>> What do you mean with "thread count"?
>>> Which class and method do you use to "increase"
>>> it?
>>> Why do you increase it?
>>> (You can process responses of many devices
>>> with a single thread)
>>> Do you have enough memory for the threads?
>>> (150*1MB = 150MB)
>>>
>>> Best regards,
>>> Frank
>>>
>>>
>>> On 26.01.2011 00:28, loaner45244 at mypacks.net wrote:
>>>> Hi All,
>>>>
>>>> We're running an old version of snmp4j (v1.7.1) where we are
>>>> see-ing a peculiar behavior with respect to how snmp4j handles
>>>> SNMP responses if the thread count is increased.
>>>>
>>>> Our default setting is 50 threads and when that value is increased to 150,
>>>> the SNMP response timeouts expire. We know that the peer has the ability
>>>> to send back responses even with 150 threads so any help in debugging this
>>>> would be appreciated.
>>>>
>>>> In particular:
>>>>
>>>> 1. The usual suspect is that this may be just inherent behavior
>>>>      of the old stack. Can anyone confirm if they have seen similar issues?
>>>>
>>>> 2. What kind of debugging can be employ to understand this behavior? Are there
>>>>      logs that could identify the reason why timeouts may be occurring?
>>>>
>>>> 3. Are there any known enhancements to the latest snmp4j code that address
>>>>      performance and timeout issues seen in the past? (to make it worth pursuing).
>>>>
>>>> Thanks,
>>>>
>>>> HA
>>>> _______________________________________________
>>>> SNMP4J mailing list
>>>> SNMP4J at agentpp.org
>>>> 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
>>> SNMP4J at agentpp.org
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com




More information about the SNMP4J mailing list