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=10... 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
From des at des.no Wed Mar 14 13:16:52 2007 From: des at des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed Mar 14 13:17:02 2007 Subject: [Nav-dev] Missing import? Message-ID: <86wt1k3tqj.fsf@dwp.des.no>
NAV 3.2.1 "out of the box" on FreeBSD 6.2-RELEASE, after logging in as admin / admin, clicking on any link on the front page results in the following: Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/local/nav/lib/python/nav/web/__init__.py", line 62, in headerparserhandler nav.web.auth.authenticate(req) File "/usr/local/nav/lib/python/nav/web/auth.py", line 102, in authenticate if not checkAuthorization(user, req.unparsed_uri): File "/usr/local/nav/lib/python/nav/web/auth.py", line 52, in checkAuthorization return nav.auth.hasPrivilege(user, 'web_access', uri) AttributeError: 'module' object has no attribute 'auth' The following one-line fix seems to solve the problem for me: --- subsystem/webFront/lib/nav/web/auth.py.orig Tue Mar 13 11:59:25 2007 +++ subsystem/webFront/lib/nav/web/auth.py Wed Mar 14 12:09:35 2007 @@ -30,6 +30,7 @@ import nav import logging +from nav import auth from nav import db from nav.db import navprofiles from nav.web.preferences import Preferences, Link However, I wouldn't expect a bug like this to slip into a release, so I have to wonder if something else is wrong - a missing PythonOption perhaps? Unfortunately, I'm not very familiar with Python. DES -- Dag-Erling Sm?rgrav - des@des.no