Bug 220749 - Background Scanning
Background Scanning
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Code
7.3
All All
: P3 (vote)
: 7.3
Assigned To: Tomas Stupka
issues@versioncontrol
EXCEPTIONS_REPORT SCAN_CANCELED
: API, API_REVIEW_FAST
Depends on: 221831
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-24 12:27 UTC by Exceptions Reporter
Modified: 2012-11-16 08:50 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (1.04 KB, text/plain)
2012-10-24 12:27 UTC, Exceptions Reporter
Details
api patch (5.62 KB, patch)
2012-11-01 12:25 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2012-10-24 12:27:54 UTC
This bug was originally marked as duplicate of bug 194810, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 7.3 Beta (Build 201210011125)
VM: Java HotSpot(TM) Client VM, 23.5-b02, Java(TM) SE Runtime Environment, 1.7.0_09-b05
OS: Windows 7

User Comments:
GUEST: Trying to run simple java class with main, the background scanning blocks it and message appears saying "Classpath scanning, wait please" or something...

GUEST: Cancelled background task scanning projects

GUEST: It's always doing a background scanning then a popup appears telling me the IDE has been unresponsive.




Stacktrace: 
java.lang.Exception: Scan canceled.
   at java.lang.Thread.getStackTrace(Thread.java:0)
   at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:113)
   at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:106)
   at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.stateChanged(RepositoryUpdater.java:579)
   at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:133)
   at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:119)
Comment 1 Exceptions Reporter 2012-10-24 12:27:56 UTC
Created attachment 126464 [details]
stacktrace
Comment 2 Tomas Zezula 2012-10-24 18:17:30 UTC
621628: Scan after svn move - legal.

617648 & 615018 & 612078 & 568834: VcsVisibilityQueryImplementation changes the file visibility, newly visible fiels needs to be rescanned.

The events from VcsVisibilityQueryImplementation are questionable as they are global and affect whole IDE. All the roots need to be rechecked for up to date (time stamp checking). Please evaluate if they are needed. Shouldn't they affect just single root? If so the VisibilityQuery API should be extended to provide the changed root (removes a need to time stamp check the unaffected roots).
Comment 3 Tomas Stupka 2012-10-24 18:36:05 UTC
> Shouldn't they affect just single root? 
> If so the VisibilityQuery API should be extended to
> provide the changed root (removes a need to time stamp check the unaffected
> roots).
yes, VCS knows which files are affected by the visibility change and could (if provided by VQ) notify only the affected files or their common roots
Comment 4 Milos Kleint 2012-11-01 08:23:33 UTC
The simple api change appears to be to create a subclass of ChangeEvent that would list the FileObjects affected and be passed to ChangeListeners listening on VisibilityQuery. Ok for everyone?
Comment 5 Tomas Zezula 2012-11-01 08:55:40 UTC
OK for me.
Comment 6 Milos Kleint 2012-11-01 12:25:19 UTC
Created attachment 126914 [details]
api patch
Comment 7 Milos Kleint 2012-11-01 12:27:30 UTC
please review this small api change to communicate between vcs and java subsystems.
Comment 8 Tomas Zezula 2012-11-01 13:47:05 UTC
The patch is OK for me (java, parsing).
Comment 9 Quality Engineering 2012-11-03 02:41:54 UTC
Integrated into 'main-golden', will be available in build *201211030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/f009a4981039
User: Milos Kleint <mkleint@netbeans.org>
Log: #220749 stop using ChangeSupport we will need to pass custom ChangeEvent subclass in some cases
Comment 10 greggwon 2012-11-08 14:15:34 UTC
How many listeners would be added to this List?  If it's more than a couple, or the list will be very volatile, then "synchronized" should not be used to manage this list.  A ConcurrentHashMap<K,K> would be a better choice, because then no one will be blocked.  This is very important for a volatile list.  In order traversal doesn't appear to be a problem, and the iterator for CHM will also not hold off access to the list of listeners.  If notifications need to be ordered, then they should go into a Queue which can then be fed to a single thread traversing the list and doing the notifications.  That complicates the design of the class more, from a logic perspective, but will make it much more performant, and help with easing the "delays" users see when interacting with VCS.
Comment 11 Milos Kleint 2012-11-09 08:05:43 UTC
http://hg.netbeans.org/core-main/rev/44c501387c00

reassigning to vcs to implement the changeevent subclass
Comment 12 Tomas Stupka 2012-11-09 15:45:50 UTC
fixed in core-main #e6efd2712c53
Comment 13 Tomas Stupka 2012-11-09 15:48:15 UTC
(In reply to comment #12)
> fixed in core-main #e6efd2712c53
for partially for cases when the IDE explicitly queries a files visibility

one more fix will follow for cases when vsc fires because of a status change. see also issue #221831
Comment 14 Quality Engineering 2012-11-10 03:27:19 UTC
Integrated into 'main-golden', will be available in build *201211100001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/44c501387c00
User: Milos Kleint <mkleint@netbeans.org>
Log: #220749 api adding a ChangeEvent subclass carrying more information about VisibilityQuery changes
Comment 15 Quality Engineering 2012-11-11 03:16:48 UTC
Integrated into 'main-golden', will be available in build *201211110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e6efd2712c53
User: Tomas Stupka <tstupka@netbeans.org>
Log: in case particular files are know then also fire visibility change providing list of those files
Issue #220749 - Background Scanning
Comment 16 Jaroslav Tulach 2012-11-13 19:15:26 UTC
FYI: I can see a sigtest report from Nov 10:

> email: api-changes@netbeans.org
> SignatureTest report
> Base version: 1.32
> Tested version: 1.32
> Check mode: src [throws normalized]
> Constant checking: on
>
>
> Added Classes
> -------------
>
> org.netbeans.spi.queries.VisibilityQueryChangeEvent


E.g. no version change (1.32 -> 1.32) and an API change. Such API changeset should not be allowed to propagate to main-silver. But probably it is some merge issue, as I can see that 44c501387c00 properly changed version from 1.31 to 1.32... who knows, the log files from push-core-main are already gone.
Comment 17 Tomas Stupka 2012-11-16 08:50:59 UTC
> (In reply to comment #12)
> fix will follow for cases when vsc fires because of a status change. see also issue #221831
fixed in core-main #6caef408346c and core-main #5637f846d4e7


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo