Inconsistent dhkickstart exchange for SNMPv3

Hi Frank,

I’m trying run some SNMPv3 calls against the SNMP4J-Agent but I’m getting inconsistent behaviour when increasing the number of requests to a number of simulated ‘devices’ in the agent. The behaviour I’m seeing is the dhkickstart is returned properly when dealing with 400 devices, but when the amount is increased over 500 up to say 1000 the exchange fails to find the entry in the table

This is an example of one of the failing devices (we append the simulated IP as part of the OID so the agent knows which device it’s referring to)

This is an example of one that’s resolving the dhkickstart value properly

Both devices however go through the same processing of registering their kickstart values and I saw no problems when dealing with 400 devices, but an inconsistent amount of devices will fail (anywhere from 16-9) when that number is increased to 1k.

Is there a upper limitation on how many concurrent calls to the agent it can support?
Is there anyway to increase that? I did see the threadPool associated with the CommandProcessor, but increasing the number of threads in the pool didn’t seem to smooth out the exchange.
Is there another thread pool that deals with resolving the dhkickstart values I’m missing?

Any ideas would be helpful. Thanks!


From the “failing” log, the agent is the problem because it has no values for the requested information. Is there an error in your test setup?

There is no “special” thread pool. Most of the time the UDP buffer of the operating system is the limiting factor when dealing with many devices.

Hi Frank
We figured out a solution. In our properties we had the snmp4j.tableSizeLimit. set to 1000, each mock device we had had 3 entries for it’s kickstart table. Increasing that limit to 5000 solved our problem. Thanks for your comment before.