[AGENT++] Persistent storage of AGENT++ configuration

[Alex Agranov]

I played with this some more - and now I'm getting some really weird results:

1) the problem seems to be only with snmpNotifyTable, which is initially empty - i.e. I don't add entries to it prior to calling mib->init()

2) the problem seems to affect ONLY a very specific row in this table: the one with index "EMS" (69.77.83) - this _specific_ row disappears from the table after I restart my application; I checked the binary file on the disk and the data for "EMS" row is there - but it's invisible via SNMP;
if I create rows with other indexes - everything works as expected (they are restored upon application restart)

Looks like some weird bug in serialize()/deserialize() implementation, doesn't it?

Cheers,
     Alex

-----Original Message-----
From: Alex Agranov
Sent: Thursday, April 24, 2008 13:50
To: 'Frank Fock'; 'agentpp at agentpp.org'
Subject: RE: [AGENT++] Persistent storage of AGENT++ configuration

Hi,

I think that I'm making some progress with the persistent storage of MIB data, but I still have some issues with it. I created a small class that inherits from MibEntry and it registers for notification from all persistent entries in my MIB. When it receives notification - it calls mib->save_all() - thus updating the persistent copy on disk.

Up until this point everything works nicely: when I add a new entry e.g. in snmpNotifyTable - change_notification() method of my MibEntry class instance is called and it saves all new MIB data to disk. I checked snmpNotificationMIB. file on disk - and although it's in binary format, it clearly contains my new entry. So far so good! :)

Now comes the part that doesn't work for me - when I restart my application, it calls mib->init() which is supposed to load all persistent MIB objects from disk. In fact in DEBUG logs I see that it does that:

20080424.09:17:00: 14860: (4)DEBUG  : MibTable: deserialize: reading table (table)(size): (1.3.6.1.6.3.12.1.3.1), (0)
20080424.09:17:00: 14860: (4)DEBUG  : MibTable: deserialize: reading table (table)(size): (1.3.6.1.6.3.13.1.1.1), (92)
20080424.09:17:00: 14860: (4)EVENT  : MibTable: deserialize: loading row (table)(index)(bytes remaining): (1.3.6.1.6.3.13.1.1.1), (69.77.83), (0)
2

It seems to work - because when I call save_all() immediately afterwards - the snmpNotificationMIB. file that is created on disk has the same data as before (including data of my previously created entry). However when I try to get data from the snmpNotifyTable via SNMP interface - the table is empty.

20080424.10:37:40: 15140: (7)DEBUG  : Vacm: Access requested for: (viewName) (oid): (All), (1.3.6.1.6.3.13.1.1.1)
20080424.10:37:40: 15140: (7)DEBUG  : Vacm: isInMibView: (viewName) (subtree): (All), (1.3.6.1.6.3.13.1.1.1)
20080424.10:37:40: 15140: (1)DEBUG  : TaskManager: task manager found
20080424.10:37:40: 15140: (2)DEBUG  : TaskManager: after notify
20080424.10:37:40: 15140: (2)EVENT  : Agent: starting thread execution (pduType)(subrequests): (165), (1)
20080424.10:37:40: 15140: (2)EVENT  : Mib: process request: getbulk request, oid: (0), (1.3.6.1.6.3.13.1.1.1)
20080424.10:37:40: 15140: (6)DEBUG  : Mib: getbulk: processing (non repeaters)(max rep): (0), (10)
20080424.10:37:40: 15140: (6)DEBUG  : Mib: getbulk: processing repeaters: (0)
20080424.10:37:40: 15140: (6)DEBUG  : Mib: getbulk: processing (id)(until)(oid): (0), (1), (1.3.6.1.6.3.13.1.1.1), (2)
20080424.10:37:40: 15140: (7)DEBUG  : Vacm: Access requested for: (viewName) (oid): (All), (1.3.6.1.6.3.15.1.1.1.0)
20080424.10:37:40: 15140: (7)DEBUG  : Vacm: isInMibView: (viewName) (subtree): (All), (1.3.6.1.6.3.15.1.1.1.0)
2

What am I doing wrong this time? :)

Thank you in advance,
    Alex

This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message