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.
Reproduced with RC2 build: Product Version: NetBeans IDE 6.7 RC2 (Build 200906042131) Java: 1.6.0_07; Java HotSpot(TM) 64-Bit Server VM 1.6.0_07-b06-57 System: Mac OS X version 10.5.7 running on x86_64; MacRoman; en_US (nb) 1. Create a new JavaSE project 2. Open an existing project from NetBeans sources, e.g. java.project 3. Go to the JavaSE project's properties 4. Click on a few categories on the left and press OK The "Scanning projects..." progress bar appears and keeps going for a long time, more than 1 minute. This is not adequate relative to the size of the J2SE project. I suspect the IDE is unnecessarily scanning NetBeans sources.
#165634?
Issue 165634 looks possibly related, but the changes related to 165634 were done more than a week before before RC2. Should I reopen that one and close this one as a duplicate?
To my knowledge, the change for #165634 never made it into the release67 branch (would be http://hg.netbeans.org/release67/rev/26d2a0f4d858 but that does not exist).
Ah, you are right. I see in the discussion in issue 165257 (which is another duplicate of this) that the fix is considered too risky. On the other hand, users *still* continue to complain about scanning performance even with RC2. I'll leave it up to you to decide whether this is a stopper.
Petr, could you please do the same in a dev build, which has the fix from #165257? If this indeed fixed the problem then we should probably transplant it to release67.
Unfortunately Petr is right, tested following scenario : - start with new userdir - open main-solver/editor project - create new J2SE project - close main-silver/editor project - open Properties on J2SE project node (no change) - push OK -> it looks like all source roots even from already closed NB project are scanned once again... see log file with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE -J-Dorg.netbeans.modules.java.source.indexing.JavaIndex.level=FINE
I tested with 6.8 trunk build (#770 from http://bertram.netbeans.org/hudson/job/web-main/) and the situation is much better: there is a 'scan in progress' dialog, but only for a short while.
Created attachment 83324 [details] log file with enabled logging
Created attachment 83326 [details] log file from NB 6.8 (200906080201)
Ok, thanks, I'm now trying to backport 26d2a0f4d858 to my local clone of release67 and run some tests. If it proves fixing the problem I'll transplant it and push the changes.
This doesn't happen with 6.5
Seconded, I wasn't able to reproduce the problem in 6.5 either.
The problem is with projects which have transitive dependency on the "closed" projects. The middle layer not registered to the GlobalPathRegistry and such a ClassPath's livecycle is tracked by the WeakReference. Until the reference is freed the class path is scanned. The same code was also in 6.0, 6.5. The strange is why the projects are scanned and not ignored by the scanned2Dependencies check. When the sourceRoot is already scanned it becomes a part of this map and other try of the scan of such a root should be skipped.
http://hg.netbeans.org/jet-main/rev/26d2a0f4d858 - fix for #165257, also needs to be transplanted http://hg.netbeans.org/jet-main/rev/987075c7de3b - maybe not be needed in release67, but should not harm anything; I prefer to transplant it as well http://hg.netbeans.org/jet-main/rev/b203bce68aee - the main fix for this issue Since trunk and release67 are quite different now, I'm going to locally move these fixes to release67 and verify that they really solve the problem. If not, we will have to find out why and maybe introduce something just for release67.
The fixes seem to work fine in release67. I also had to backport http://hg.netbeans.org/jet-main/rev/fcd9e70bc63d and http://hg.netbeans.org/jet-main/rev/465c92cb643c, which just add more logging, but the other fixes touched the same code and would not merge. These two additional changesets are safe (no semantic changes, just logging). QE please verify the fixes in trunk. I'll ask for peer review and proceed with transplantation as soon as you give me thumbs up.
The attached diffs look OK.
Integrated into 'main-golden', will be available in build *200906121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b203bce68aee User: Vita Stejskal <vstejskal@netbeans.org> Log: #166715: don't use uknown roots when computing the dependencies from scratch; they should be discovered along the way; if they are not it means that they are no longer needed by any of the opened projects
verified in trunk
The changsets have been transplanted to release67 clone: 26d2a0f4d858 - http://hg.netbeans.org/release67/rev/629e33a7d2a1 987075c7de3b - http://hg.netbeans.org/release67/rev/46635ac494d7 b203bce68aee - http://hg.netbeans.org/release67/rev/54de91d1363d fcd9e70bc63d - http://hg.netbeans.org/release67/rev/0360dbda0f15 465c92cb643c - http://hg.netbeans.org/release67/rev/e5cfed4dd402
verified in RC3
*** Issue 167165 has been marked as a duplicate of this issue. ***
This is happening again in today's build of 6.8, reopening. 1. I opened a NB module project 2. Several hours later, I opened a Maven project 3. Changed target server in the Maven project and closed the properties dialog Scanning was triggered for a long time and it went through the NetBeans sources.
I need the logfile with increased logging in RepositoryUpdater and JavaIndex. -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE -J-Dorg.netbeans.modules.java.source.indexing.JavaIndex.level=FINE
Are you saying this does not happen to you and you can not reproduce? I will attach the logfile, I will get to this tomorrow.
Created attachment 91038 [details] Log file as a zip file I am attaching the log file with the logging messages. The steps to reproduce are even simpler than described above, namely: 1. Opened a NB module project (web.core.syntax in my case) 2. Opened a Maven web application project
Reopening, sorry it took me so long to provide the data.
Created attachment 91278 [details] Proposed patch - please review I have a patch, which fixes the problem. Tomasi could you please review? Thanks
Thanks. Since this is a regression, it would be useful to add a unit test to make sure it does not regress again.
The patch is good. >Since this is a regression, it would be useful to add a unit test to make sure it does not regress again. I doubt it's a regression as the code increasing the scans is there for 12 days and before it was there in 6.5 In the 6.5 there was no possibility how to limit the scan - always everything was rescanned (the PathRegistry had no change types). It's hard to create an unit test for this as an unit test should be small simple (btw these test are there, more than 10 test for it) but this requires a more complicated set up (both source and binary libraries with dependencies, several types of changes). Maybe some kind of functional test.
http://hg.netbeans.org/jet-main/rev/dd494bd9620a Tomas is right on the fact that this problem is different than the original one. Also the steps are different. I didn't want to open a new defect and produce a lot of bugzilla spam, but technically this would have been the right approach.
Ok, I see. Thanks again for the fix.
Integrated into 'main-golden', will be available in build *200911200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/dd494bd9620a User: Vita Stejskal <vstejskal@netbeans.org> Log: #166715: compute differencies in binary roots and their dependencies only when we really traversed all the dependecies
the fix seem to be ok -> verified