[SNMP4J] some SNMP4j issues...

[Renato Araújo Ferreira]

Frank,

I found that someone that configured the system to try to use the wrong port 
(555555), but when I solved this error the timeout problem and the 
ConcurrentModificationException stopped to ocurr. Is it an incorrect 
exception handling of IllegalArgumentException inside the 
DefaultUdpTransportMapping? Because an isolated error affect all SNMP 
processing of snmp4j in VM.

Renato A. Ferreira

----- Original Message ----- 
From: "Frank Fock" <fock at agentpp.com>
To: "Renato Araújo Ferreira" <renato at flexvision.com.br>
Cc: <snmp4j at agentpp.org>
Sent: Wednesday, August 27, 2008 6:58 PM
Subject: Re: [SNMP4J] some SNMP4j issues...


> Hello Renato,
>
> Are you sure that each session is closed only once?
> The last error you reported (ConcurrentMofificationException)
> suggests that.
>
> The other errors/delays are caused by Java and
> probably caused by heavy session (=UDP port)
> creation and closing.
> Changing the JRE (version) may help too.
>
> Best regards,
> Frank
>
>
> Renato Araújo Ferreira wrote:
>> Hello all,
>>
>> I´m trying to use snmp4j in my application. It worked fine for single 
>> threaded application, but I found some problems in a multithreaded 
>> environment.
>>
>> Each thread has your own session initialized with:
>>
>>    TransportMapping transporteUDP = new DefaultUdpTransportMapping();
>>    this.sessaoSNMP = new Snmp(transporteUDP);
>>    this.sessaoSNMP.listen();
>>
>> And closed with:
>>
>>    this.sessaoSNMP.close();
>>
>> These sessions are reused in all thread's life cycle only changing their 
>> CommunityTarget and UserTarget. But, at end of process, one last target 
>> (randomly, not the same) always wait too many time, between 250 and 300 
>> seconds, in method org.snmp4j.Snmp.get with this stack:
>>
>>    "DefaultUDPTransportMapping_1.1.0.160/0" daemon prio=1 tid=0x086b8070 
>> nid=0x7c51 runnable [0x8b948000..0x8b948ec0]
>>            at java.net.PlainDatagramSocketImpl.receive0(Native Method)
>>            at 
>> java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
>>            - locked <0x926b9918> (a java.net.PlainDatagramSocketImpl)
>>            at java.net.DatagramSocket.receive(DatagramSocket.java:712)
>>            - locked <0xb1b6d400> (a java.net.DatagramPacket)
>>            - locked <0x926bacd0> (a java.net.DatagramSocket)
>>            at 
>> org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(Unknown 
>> Source)
>>            at java.lang.Thread.run(Thread.java:595)
>>            at 
>> org.snmp4j.util.DefaultThreadFactory$WorkerThread.run(Unknown Source)
>>
>>    "Coletando: public at 00-18-F3-C7-71-05" daemon prio=1 tid=0x086244d8 
>> nid=0x7c38 in Object.wait() [0x8c76a000..0x8c76ae40]
>>            at java.lang.Object.wait(Native Method)
>>            - waiting on <0x92ae9730> (a 
>> org.snmp4j.Snmp$SyncResponseListener)
>>            at java.lang.Object.wait(Object.java:474)
>>            at org.snmp4j.Snmp.send(Unknown Source)
>>            - locked <0x92ae9730> (a org.snmp4j.Snmp$SyncResponseListener)
>>            at org.snmp4j.Snmp.send(Unknown Source)
>>            at org.snmp4j.Snmp.get(Unknown Source)
>>            ...
>>
>> Sometimes I'm getting a "IllegalArgumentException: port out of 
>> range:555555" error with this stack:
>>
>>    java.lang.IllegalArgumentException: port out of range:555555
>>            at 
>> java.net.InetSocketAddress.<init>(InetSocketAddress.java:83)
>>            at 
>> org.snmp4j.transport.DefaultUdpTransportMapping.sendMessage(Unknown 
>> Source)
>>            at org.snmp4j.MessageDispatcherImpl.sendMessage(Unknown 
>> Source)
>>            at org.snmp4j.MessageDispatcherImpl.sendPdu(Unknown Source)
>>            at org.snmp4j.Snmp.sendMessage(Unknown Source)
>>            at org.snmp4j.Snmp$PendingRequest.run(Unknown Source)
>>            at java.util.TimerThread.mainLoop(Timer.java:512)
>>            at java.util.TimerThread.run(Timer.java:462)
>>
>> And, finally, sometimes I'm getting a "ConcurrentModificationException" 
>> error using a iterator (method Iterator.next()) at end of process, when 
>> all the SNMP communications are already finished. This code was already 
>> there before I'm using SNMP4j and, as I found some information about bugs 
>> like this in the web, I think so that could be something with my 
>> implementation of SNMP4j.
>>
>> OMG, a large email, but could someone help me??
>>
>> Thankss....
>>
>> Renato A. Ferreira
>> _______________________________________________
>> 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
>