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:||versioncontrol||Reporter:||Exceptions Reporter <exceptions_reporter>|
|Component:||Code||Assignee:||Tomas Stupka <tstupka>|
|Severity:||normal||CC:||aws, marines, tzezula|
|Issue Type:||DEFECT||Exception Reporter:||194015|
|Bug Depends on:||221831|
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 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 <firstname.lastname@example.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 <email@example.com> 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 <firstname.lastname@example.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: email@example.com > 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.