[SNMP4J] problem receiving v3Traps over TCP using DefaultTcpTransportMapping

[shanmugam vairavan]

> Hi Frank
>
> Thank you for your response. I accept that we need to have really good
> hardware configuration to handle such kind of load.
>
>
>
> But even then, in any case the DefaultTcpTransportListener should not
> deadlock right? During peak load it should gracefully reject any new
> incoming connections rather going into a deadlock.
>
> Thanks
> Shanmugam.VE
>
>
> On Sat, Dec 13, 2008 at 12:06 AM, Frank Fock <fock at agentpp.com> wrote:
>
>> Hi,
>>
>> From your description I conclude that the
>> trap senders open a new TCP connection for
>> each trap within 10 milliseconds, is that
>> right?
>>
>> That's a bad design (even for testing), because
>> establishing a TCP connection is very expensive
>> and when closing it, resources may not be release
>> immediately.
>>
>> 500KByte Traps are questionable too. If there are
>> thousands of trap senders, you will need a 10Gbps
>> LAN instead 100Mbps and a really fast machine to
>> process the data.
>>
>> Best regards,
>> Frank
>>
>> shanmugam vairavan wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I am using snmp4j (v1.9.2) for writing a V3Trap listener. The listener
>>> should be able to receive 'hundreds of thousands' of V3Traps per day,
>>> over
>>> TCP from multiple senders. When testing my listener implementation I
>>> found
>>> that my listener goes into a deadlock, and stops listening when the load
>>> increases (say 2 senders, sending Traps of size 500kilobytes per
>>> 10milliseconds). The listener is running on a machine with the following
>>> configuration: Intel Pentium (D) CPU 3.40GHz, Windows XP Professional
>>> SP3,
>>> 2GB RAM, 100Mbps LAN.
>>>
>>>
>>>
>>> When the problem occurred, TCPView shows around 40 TCP connections (for
>>> my
>>> listener port) with almost all in ESTABLISHED state, barring a few in
>>> CLOSE_WAIT state. I have attached the same.
>>>
>>>
>>>
>>> Debug reveled the reason for this problem being the
>>> java.nio.channels.Selector.select() call in
>>> DefaultTcpTransportMapping$ServerThread.run() method blocks forever. I
>>> even
>>> tried modifying the call with a timeout,
>>> java.nio.channels.Selector.select(10000). Now there is no deadlock but
>>> when
>>> the load increases the call always returns 0.
>>>
>>>
>>>
>>> Has anyone faced a similar situation before? Is this problem inherent to
>>> TCP
>>> or the Sun's NIO implementation? Please provide me some pointers to solve
>>> the same.
>>>
>>>
>>>
>>> PS: Please let me know if you need any further information regarding my
>>> setup and code.
>>>
>>>
>>>
>>> Thanks & Regards
>>>
>>> Shanmugam.VE
>>> _______________________________________________
>>> SNMP4J mailing list
>>> SNMP4J at agentpp.org
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>>
>>
>> --
>> AGENT++
>> http://www.agentpp.com
>> http://www.mibexplorer.com
>> http://www.mibdesigner.com
>>
>>
>