View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005542||SUMo||Refactoring||public||2019-06-10 15:15||2019-07-24 17:58|
|Platform||i7-8000 notebook||OS||Windows 10||OS Version||1809 64-bit|
|Target Version||Short term||Fixed in Version|
|Summary||0005542: provide other logging options for verbose mode storage location|
|Description||Considering the volume for scanning action on my notebook without any development environment, it is no longer conveniant to use the current location for storing log file in verbose mode. The scan action will need more records in verbose mode as the current location permits. As already reported, the current location for storing log file seems to have a limit of 10000 records. |
I didn't check which location SUMo uses if used in portable mode for logging in standard and in verbose mode. May this provide some alternative storage location for the installed instance at least for verbose mode without that operating system limit of 10000 records?
|Additional Information||During scanning, the counter of detected objects increases unto almost 8500 objects as I don't have installed any development environment and not yet included some system administration tools already installed. These almost 8500 objects are cleaned up to result in almost 1800 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, 3 exclude folders to customize additional folders for irrelevant data, and 60 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 1423 elements for 1784 elements of its load list and according to which criteria elements are skipped of its cache before scanning?
And why does SUMo log report a cache size of 1434 elements for 1799 elements of its load list and according to which criteria elements are skipped of its cache after scanning and checking?
|Tags||No tags attached.|
SUMo.scan.20190610.log (260,478 bytes)
Why has this feature request category refactoring?
Refactoring means redesign WITHOUT any change of feature set. And as far as I see, this request is a change in the feature set, adding a feature not yet existing as formulated in the subject.
So do you prefer to split this feature request into a refactoring one for the volume and performance handling and keep this one for the feature extension?
You may need even more refactoring issues for a variety of volume and performance issues. And I can't see enough support for analysis.
|2019-06-10 15:15||wolf||New Issue|
|2019-06-10 15:15||wolf||Issue generated from: 0005541|
|2019-06-10 15:15||wolf||Relationship added||related to 0005541|
|2019-06-10 17:00||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2019-06-10 17:00||Kyle_Katarn||Status||new => acknowledged|
|2019-06-10 17:08||Kyle_Katarn||Target Version||=> Short term|
|2019-07-24 17:32||wolf||Note Added: 0003597|
|2019-07-24 17:58||wolf||Issue cloned: 0005594|
|2019-07-24 17:58||wolf||Relationship added||related to 0005594|