This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE 7.3.1 (Build 201305272201) Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01 Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b12 System: Mac OS X version 10.8.3 running on x86_64; US-ASCII; en_US (nb) User directory: /Users/tomas/Library/Application Support/NetBeans/7.3.1 Cache directory: /Users/tomas/Library/Caches/NetBeans/7.3.1 ----------------- - start fresh 7.3.1 - open openide.filesystems - cancel scanning - complete scanning took ~ 41s, no dialog with possibility to report - ok - now open openide.windows - cancel scanning - complete scanning took ~ 9s, no dialog with possibility to report - ok - now open projects.libraries - cancel scanning - dialog with possibility to report scan cancel appears (to which canceled scanning is related?!), cancel it - complete scanning took ~ 26s - after a while of ide being idle, dialog with possibility to report scan cancel appears for the second time, cancel it again - after another while of ide being idle, dialog with possibility to report scan cancel appears for third time, cancel it again => seems like each scan cancel produces report dialog, which is fairly delayed from the actual scan cancel. I was able to reproduce with steps: - start fresh 7.3.1 - open openide.filesystems - cancel scanning (scanning took < 1min) - wait for some time (minutes) - report scan dialog appeared after some time If you won't be able to reproduce (which is unlikely), I can attach at least log file. Let me know if you want to resolve this for 7.3.1; Not a critical bug, but may cause a high number of undesired slow scanning reports from 7.3.1
This correction was done after consulting Tomas Z. as a response to issue #230086; see suggestions posted in that bug.
Note that the delayed report actually collects statistics (and in 7.4 also self-profiles the IDE) until the report offer is displayed to the user, so the report would most probably contain some relevant data. The number of reports might be increased as some users cancel the scanning in order to disable or avoid the process entirely (which is forbidden)
ok, thanks for clarification, I misunderstood the original point; it seemed to me unlikely that any valuable data will be generated after 3 minutes, if the original scanning at time of showing report dialog is not running any more. I guess you can close this, sorry for confusion.
Oh, I overlooked the path: if the entire scanning takes < 3mins (or the threshold configured). Useless report will be posted in that case, indeed. Sorry for the misunderstanding. The fix should be fairly easy/non harmful.
Fixed in http://hg.netbeans.org/jet-main/rev/d30dd94b45b9
Ok, so to summarise - if someone will cancel running scanning at some point, data collection starts after 3 minutes if and only if scanning is still running, is that correct? If so, do you want this for 7.3.1.? I guess it makes sense to backport this...
It does; once it is verified, it could be backported
verified in custom trunk build, please backport to 7.3.1
Please backport as soon as possible, so we can start another (and hopefully the last) build. Thanks in advance.
Backported in rev http://hg.netbeans.org/releases/rev/b9d3a582ef54, pending verification in 7.3.1
Integrated into 'releases', will be available in build *201305291404* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/b9d3a582ef54 User: Svata Dedic <sdedic@netbeans.org> Log: #230369: delayed reports are not issued if the scan finishes during the threshold time [backport from trunk, d30dd94b45b9]
Integrated into 'main-golden', will be available in build *201305292301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d30dd94b45b9 User: Svata Dedic <sdedic@netbeans.org> Log: #230369: do not report finished scans - took less than .cancelTreshold secs
verified in bits from staging UC.