DefaultUDPTransportMapping.setPriority is not functional

SNMP4J
1

Hello Frank,

I am using SNMP4j in a massive multithreaded environment. When working with async SNMPv3 requests it seems that some of the response PDUs are not handled by the library, or they are received seconds after their timestamp in the tcpdump packet capture file.

I may have made some mistakes or the receiver thread was not executed soon enough.

I have tried increasing the receiver thread priority via DefaultUDPTransportMapping.setPriority(10) before and after the listen() call, but the getPriority always returns 5. After checking the source it appears that the DefaultUDPTransportMapping.listener object is a DefaultThreadFactory.WorkerThread which contains the java.lang.Thread and it does not extend it. Therefore the setPriority does nothing and the getPriority returns Thread.NORM_PRIORITY. DefaultUDPTransportMapping.setThreadName and getThreadName might not work too.

Please check if this is intentional or it was simply not updated.

Kind regards,
Zoltan

2

Hi Zoltan,
I will check the code and fix it if necessary.
But even then setting the priorities will likely not help to solve the problem you reported.
You need to make sure that your handler code returns immediately or use a multi-threaded message dispatcher.
If that does not help either you need to increase udp buffer sizes.
Best regards
Frank

3

Setting the priority and thread name will be working again in SNMP4J 3.6.0. This bug was a regression introduced when the DefaultThreadFactory in SNMP4J 1.8.

4

Thank you very much!