View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005675||SUMo||New Feature||public||2019-09-01 19:06||2019-09-01 19:07|
|Platform||i7-8000 notebook||OS||Windows 10||OS Version||1809 64-bit|
|Target Version||Long term|
|Summary||0005675: provide other logging options for verbose mode|
|Description||Considering the volume for scanning action on my notebook without any development environment, it is no longer conveniant NOT TO PROVIDE MORE VERBOSE OPTIONS. It seems to me useful to provide a larger variety of filtering options for verbose mode and probably too for standard (operation and logging) mode.|
Why shall standard logging be always additive, adding one log record after the other?
Can't it be useful to replace (overwrite) or suppress uninteresting records in the log file?
In standard logging mode, a check phase doesn't fit into the log file. When the check action in standard log mode finishes, the first 1250 check operations have already been overwritten although I've added about 1200 entries to the previous 60 entries to the ignore list this week and hence out of checking.
|Additional Information||During scanning, the counter of detected objects increases unto almost 22500 objects as I don't have installed any development environment and not yet included some system administration tools already installed. These almost 22500 objects are cleaned up to result in almost 6240 components and products being reported.|
I configured scan action not to do additional load and check actions. I further configured it to to deep scanning, 19 additional folders of standard locations and portable locations still ignored otherwise, 10 exclude folders to customize additional folders for irrelevant data, and 1260 ignore list elements due to not yet proposed update to Windows 10 1903, and to include Microsoft products reporting.
BTW, why does SUMo log report a cache size of 3880 elements for 6254 elements of its load list and according to which criteria elements are skipped of its cache before scanning?
Of those 6254 elements of the load list, 6238 remain on the report list!
I expect about 13000 records on unfiltered check operation but only 10000 are kept due to default file storage location. So even in standard mode logging even alone the checking action phase doesn't fit into the log file.
With already running SUMo, repeating a check action leads to about 10 minutes of reloading and almost 25 minutes of checking!
Is this reloading really needed?
Does it make sense to switch logging to SQLite3 like some open source projects (Apache, Firefox, Thunderbird)?
Will such a switch remove the 10000 record limit?
|Tags||No tags attached.|
|2019-09-01 19:06||Kyle_Katarn||New Issue|
|2019-09-01 19:06||Kyle_Katarn||Status||new => assigned|
|2019-09-01 19:06||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2019-09-01 19:06||Kyle_Katarn||Issue generated from: 0005594|
|2019-09-01 19:06||Kyle_Katarn||Relationship added||related to 0005594|
|2019-09-01 19:07||Kyle_Katarn||Target Version||=> Long term|