Periodic Dropouts Online History
Data-Monkey opened this issue · 13 comments
I'm getting these periodic dropouts in the online history table:
This might be related to DB locks, but I'm only guessing...
The data should be saved to the DB in this method AFAIK:
db.read vs db.read_one issue?
I haven't looked into what this actually does in detail.
Do you have any error messages?
Maybe I am no longer running all the steps in the correct order. If the history runs before a scan runs it might be like that.
Are all the devices that are offline from the same scan-type?
Could it be that these calls return 0?
Line 425 in b814a85
It's also weird that this keeps happening in-between scans, but the correct values are entered after an actual scan
Ah, maybe cycle is not initialized? as its a global ?
networkscan passes in the global cycle:
Last time this SQL query was changed it was targeting a different DB table... not sure even if cycle is required (maybe removing the where statement would fix this)? Still investigating:
Just checked the DB - I think we can safely remove the where clause:
Figured it out I think - the method is called even if there is no data in the CurrentScan table. The method is called more often than before (even if a scan is not being processed) so it returns 0. Previously the method was only executed if data in the CurrentScan table were present.
Great Find!
So it must only run after a scan was actually executed.
If all the scans run and found nothing it would be correct to set everything to offline.
Yes, I remember there was a problem that I don't know how to return anything from the scan_network() method into the main loop as it is multiprocessing again. Maybe I need to call one from the other. I think it was all 1 big script before.
Is it ever possible to have no devices in CurrentScan?
The actual host of the docker should always be there, no?
Maybe we can just say if CurrentScan is empty skip the InsertOnlineHistory?
Yeeah, I think that's acceptable - it's only for stats - no other functionality is dependent on it
I added the check to run only if there are records in the CurrentScan table. Also hopefully fixed the read_one() that was not actually working when there was only 1 record in the result!
great! seems fixed:
