Some of you have noticed problems with getDeviceData running out of Java heap memory, and then getting out of sync with the PostgreSQL database driver - it ends up doing strange updates to the database.
The issue is described in this bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1675508&group_id=107608&atid=648170 For the technically inclined, here's a complete summary: I've traced the problem back to the Java SNMP package provided by drexel.edu. This package is used by the getDeviceData and getBoksMacs NAV processes to perform SNMP queries. The problem is an infinite loop, in which the library sends the same GETNEXT request over and over, and growing a list of SNMP responses until the heap is full. In a getDeviceData context, this problem can occur during OID testing of a device (This is when gDD attempts to figure which SNMP OIDs a new device supports). When the OID tester attempts to query an OID using GETNEXT requests, it uses the Java SNMP package's method for snmpwalking a MIB tree (retrieveMIBTable). If the OID is outside the MIB view of an SNMPv2c device, the device will respond with an SNMPv2 endOfMibView exception. Ufortunately, the retrieveMIBTable method of drexel's Java SNMP package treats this exception as just another value and adds it to the list of responses. Since the exception's object identifier is the same as the one used in the GETNEXT request, the method will continue to issue GETNEXT requests for the same OID until it no longer receives any response, or until it runs out of memory, whichever comes first. I've written two different patches to fix the problem in the Java SNMP Package, and I have submitted these patches to the upstream authors. The simplest patch is available at the aforementioned bug report page, for those who want to apply it themselves. I'm also planning to write a workaround for NAV. It is quite unnecessary for the NAV OID tester to walk entire SNMP tables just to test OID compatibility. Issuing a single GETNEXT request should be enough to determine whether the OID is supported or not. By doing this, the OID tester can avoid using the retrieveMIBTable method of the drexel library entirely. -- mvh Morten Brekkevold UNINETT _______________________________________________ nav-users mailing list [email protected] http://mailman.itea.ntnu.no/mailman/listinfo/nav-users
