While analyzing inappropriately loaded classes during start (see http://wiki.netbeans.org/FitnessViaWhiteAndBlackList) I realized that the up-to-date check of indexers and their indexes done on start can be flawed.
1. start the IDE open and initially index one project group
2. close the group and open another one, wait for initial index being over
3. shutdown the IDE and upgrade to new version with new indexers
4. start the new IDE (only one of the groups is open)
5. indexes for the open projects are made up-to-date
6. switch to the other project group
7. error: indexes are not upgraded
As Víťa explained to me, this is result of the indexers version check being done during start, not when one opens new projects.
Full disclosure: I am interested in this problem because proper fix is likely to remove at least following classes from the whitelist:
Plus also these classes:
I've added these classes to whitelist for now (remove them when fixed):
Why is this P2?
Unfortunately, this seems to be not only about classloading. The more sever problem is that the index consistency check may not work in some situations. I haven't tried Jarda's usecase, but the consistency check is likely not to work in this case.
*** Bug 180581 has been marked as a duplicate of this bug. ***
This only really affects users of dev builds, where a change in an indexer version in combination with the use of an existing userdir is much more likely than in a release version. In the release version there is always a new userdir and the cached indices are never imported to it.
See Issue #180581 where it was many times reported after upgrading to NetBeans v6.8 Patch 1
Actually not fixing this issue prevents from issuing patches including index changes. P2 for me
Radek, cannot we just refrain ourselves from changing the version of indexers for bugfixes that go to patch release?
BTW can you please point me to the bugs that required the change? Thanks.
ooops, I didn't want to change the priority back (yet). There was mid-air collision in our comments and I just hit "submit anyway".
We can refrain(we did because we didn't know about this bug), but its limiting and one needs to know not to do it(for patches for example)
6.9 is out, we can again use standard bug classification:
It is clear that the check for correct version of indexers "doesn't work work". True, some "workaround exists", yet it is clearly impractical and practically invalidates versioning of indexers at all. Thus "feature does not work'. Reclassifying to P2.
I agree this is P2. But arguing with the bug priority guidelines almost made me turn it back to P3 since the guidelines clearly talk about end users impact and there is none (in supported end user scenarios (using the same user dir is not officially supported between dev builds)).
As I wrote in #12, this bug is according to all standards P2. Excuses of it not being applicable if people use the system "carefully" are not appropriate in my opinion. Moreover this bug is negatively influencing performance and scalability. As such I believe it shall be P2. The team commited and uncommited to fix the problem multiple times, requesting it to go through the hassle of the waiving process would at least remind the team that this is serious issue. Can you return the priority back to P2?
 PHP patch was completely broken in 6.8 or 6.7 due to this problem
 I understand you do not want to go through waiving process, but that shall not impact the decision about priority.
As the index versions do not change for last year the bug affects anything.
"Moreover this bug is negatively influencing performance and
scalability." Can you please be more specific about this?
Ok making it P2.
Closing as wontfix.
If you feel otherwise please assign to yourself, attach a patch and reopen. Or find someone to fix it and assign to such a person. Thanks.
The fix of this bug does not itself improve performance at all. In fact the opposite is true fixing it will slow down scanning as the indexers list will be per root not global and needs to be read number of root times.
It's not P2 from the reason I've described above (no index updated for long time) and also workaround exists.
Created attachment 106883 [details]
Patch of fix attached. The indexer versions are per cache folder.
The tests are passing but the patch is quite complex and may affect any language integration.
It also affects performance as more IO is needed.
Do you plan to integrate this into 7.2?
No plans, I am sure.