Why do I get different result for the same oid using gettable?

I using gettable method to query the iftable result, the oid array is "[“”,“”,“”,“”,“”,“”,“”,“”], but I find that sometimes the result is more than hundreds of rows,but sometimes the result is only dozens of lines.What’s wrong with my code?I have tryt to set timeout with 20 seconds,but sometimes it still happen .

public List<VariableBinding[]> getTable(List oids, SnmpTarget snmpTarget) throws Exception {
Snmp snmp = SnmpComunication.getSession(snmpTarget.getSnmpVersion());
Target target = SnmpComunication.getSnmpTarget(snmp, snmpTarget);
TableUtils tableUtils = new TableUtils(snmp, new DefaultPDUFactory(PDU.GET));
OID[] columns = new OID[oids.size()];
for (int i = 0; i < oids.size(); i++) {
columns[i] = new OID(oids.get(i));
List events = tableUtils.getTable(target, columns, null, null);
List<VariableBinding[]> returnList = new ArrayList<>();
if (events.size() == 1 && events.get(0).getColumns() == null) {
return null;
} else {
for (TableEvent event : events) {
if (event.getColumns() == null || event.getColumns().length < 1) {
VariableBinding[] values = event.getColumns();
return returnList;

I think that the difference is made by the agent responding to your query.
There are several causes possible for this:

  • IO wait time when looking up interfaces on the agent (which results in slow performance in the agent)
  • lexicographic ordering error in the agent (returning cycles of the same rows, which are then ignored by SNMP4J, resulting of less rows returned by the API in the same time)
  • length of the response PDU in the agent exceeds internal limits and is returned early while following PDU is late regarding timeout
  • caching in the agent is updating while query is running which could add same devices but with new index OIDs

Can you tell me some way to fix this problem,please? I do not think the reason is timeout becuse I have set the timeout with 20 seconds,but sometimes it still happen.

No, as I wrote above, then it is some of the other issues with the agent. You cannot fix that by parameterization of the SNMP4J API (or with any other SNMP library).