1 of 1 people found this helpful
My 3.0.2 issues:
a) cannot cope with replies larger than a few KB
[it uses getbulk, and there is nothing to say that the next blobs of data returned are not larger than this. The alternative is to switch to SNMPv1, or turn the number of repeaters in the SNMP request. Neither of which is a real solution. A fixed SNMP library is available for this]
b) cannot cope properly with more than one poller
the database design does not cope with contention between pollers, e.g. if a MAC address is seen on switches on different pollers and the update process deletes from one table, and inserts into another. This locks out one poller or the other. There is a fixed SQL stored procedure which helps, but really the design should be closer to a type-2 dimension (see Ralph Kimball's excellent work on data warehouse design). Updating an existing row to show that it is no-longer current is more efficient than moving data between tables IMNSHO. I suspect that there is still a timeout or deadlock that causes (c) below.
c) the UDT business layer has a bug where if a database connection on a thread gets broken it never reconnects; the only fix for this is to restart the module engine. When you do that it will then be able to poll the devices. At this point it'll correct the job engine database (should probably fix scenario 1) [current open case since February 5th on this issue]
d) the UDT business layer does not maintain the job engine database correctly -- what you're seeing in scenario 1. If you stop the job engine, copy the blank SDF file over the existing SDF file, and then restart the job engine then it'll start working again. restarting the ModuleEngine may also fix it...
I dislike public gripe posts, since it is like a bratty child standing in a store screaming because they are not getting their way, but I've been fighting getting 3.x completely working for about four months as well, and frankly it's getting ridiculous.