After upgrading to snm4j.2.6.3 from snmp4j.2.5.8 I am facing a new issue. Traps are not listened sometimes after the start of application

0
votes

After upgrading to snm4j.2.6.3 from snmp4j.2.5.8 I am facing a new issue. Traps are not listened sometimes after the start of application, once application is restarted traps are listened as usual. During this issue traps are received on port 162(Trap receiving process) at client server but not received at 'processPdu' overridden method of interface 'CommandResponderEvent' of snmp4j. The same piece of code worked fine with snmp4j.2.5.8 without any issue.

Tried with later version snmp4j.2.7.0 and snmp4j.2.8.0 but traps itself are not listened but when I took tcpdump on trap receiving process running port 162, traps are coming to client server but not listened by snmp4j.

Note : I am using MultithreadedMessageDispatcher

I wanted to know if anybody had faced the same issue with snmp4j.2.6.3, snmp4j.2.7.0 and snmp4j.2.8.0 versions and how did you overcome this issue?

Thanks in advance!

1
snmp4j

1 Answers

0
votes

When this issue happens i.e when traps are not listened after sometime I have taken the java thread dump using jstack command. There is a thread DEADLOCK ON 'DefaultUDPTransportMapping_0.0.0.0/162' of org.snmp4j.transport.DefaultUdpTransportMapping and some threads from the thread pool created using org.snmp4j.util.ThreadPool are in "BLOCKED" state. Threads which are created to process traps remained in blocked stated without any further process.

I have shared the above details to SNMP4J team and got a confirmation from Frank Fock saying there is a bug in SNMP4J 2.6.3 ThreadPool class which was fixed in later version.

Hope this might help others also who are using SNMP4J 2.6.3 version and facing same issue.