Table addRow / deleteRows also calls setListeners

Hi all,

I’m using FriendlySNMP to manage an Agent with a lot of tables. I’m currently migrating from snmp4j 2.6 to 3.7 and I’ve run into the following issue.

In the past code like this worked well for us. Here’s the friendly getter/setter setup:

		ocpConfigTable.addGetListener(new FTableGetListener() {
			@Override
			public void get(final FTable table) {
				processOcpTable(table, true);
			}
		});

		ocpConfigTable.addSetListener(new FTableSetListener() {
			@Override
			public void set(final FTable table, final FID idRow, final FColumn col, final TableRowAction action) {
				updateOcpTable(table, idRow, col, action);
			}
		});

The update and process methods are as follows (strongly abbreviated):

    private void processOcpTable(final FTable table) {
        table.deleteAll; // Calls MOToable.removeRow once per row under the hood; this might already call our set listener
        for (;;) {
            FID row = aTable.addRow(someKey, someIdx); // calls MOTable.addRow under the hood; this will most definitely call our set listener
        }
    }

As described in the comments above, we are running into the issue that modifying the table through removeRow or createRow now calls the set listener (through afterMOChange). This was not the case with snmp4j 2.x.

Is there a way to have to have the programmatic modification of the snmp4j table not call the set listeners? I want them called only when changes are made via SNMP SET statements. I’m aware of the fact that the issue might actually lie within friendlysnmp - there has been no update since the snmp4j 2.x days.

Thanks!

I think that problem is fully „FriendlySNMP“ related. I always warned to use that wrapper API because it oversimplifies and makes it worse in the long run.
When it is not supported anymore you should migrate away from it!