Hi Kristian,
I'm debugging some getDeviceData problems that occur when devices change
type in NAV, where, among other things, OID testing sometimes does not
run properly.
Apparently, OID testing runs properly only every second time a device
changes its type (this is what my tests show when using the refresh
function and switching type several times in a row). When OID testing
does not run properly, all the OIDTester logs is that OID testing is
done, without having tested anything.
I've found that the doTest method of the OIDTester exits early because
all the OIDs are found in a MultiMap called dupeMap.
What I would like to know, if you can remember, what exactly is the
purpose of this dupeMap?
Incidentally, the netbox refresh function of gDD suddenly stops working
after an arbitrary number of refreshes and will not work again until
after a gDD restart. gDD logs the refresh event and says it will start
an immediate collection run for that box, but then proceeds to do nothing...
--
mvh
Morten Brekkevold
UNINETT
>From kreide at gmail.com Mon Jan 29 01:25:27 2007
From: kreide at gmail.com (Kristian Eide)
Date: Mon Jan 29 10:25:32 2007
Subject: [Nav-dev] Re: OidTester dupeMap
In-Reply-To: <45B5EBF8.7010602(a)uninett.no>
References: <45B5EBF8.7010602(a)uninett.no>
Message-ID: <b4c110fd0701290125i1668ea71we8fa4b812b335e7a(a)mail.gmail.com>
> I've found that the doTest method of the OIDTester exits early because
> all the OIDs are found in a MultiMap called dupeMap.
> What I would like to know, if you can remember, what exactly is the
> purpose of this dupeMap?
Sorry for the late reply, but here goes: it is used to flag a
combination of IP and OID as already tested. I added it because
testing happens in parallel and a IP/OID combination can be tried both
from testing a single OID with all IPs (netboxes) and a single IP with
all OIDs.
I remember I tried to be clever when implementing this map since I
wanted it to have O(1) lookup cost, but I have no doubt that there are
bugs in the implementation, especially since I did not write any tests
for it, something which is a necessity for testing the corner cases of
something like this. I cannot remember how entries are removed from
it, but since this is going to be tricky with the current
implementation I probably got it wrong back then (and this is probably
the source of the problem).
> Incidentally, the netbox refresh function of gDD suddenly stops working
> after an arbitrary number of refreshes and will not work again until
> after a gDD restart. gDD logs the refresh event and says it will start
> an immediate collection run for that box, but then proceeds to do nothing...
I will recommend that you add a proper test case to the queueing
mechanism and I am sure you will find this (and probably a few more)
bugs in short order.
--
Kristian
