Bug 180262 - Incorrect check of indexer's being up-to-date
Incorrect check of indexer's being up-to-date
Status: REOPENED
Product: editor
Classification: Unclassified
Component: Parsing & Indexing
6.x
All All
: P3 (vote)
: 7.2
Assigned To: Tomas Zezula
issues@editor
: PLAN
: 180581 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-04 03:36 UTC by Jaroslav Tulach
Modified: 2012-02-24 09:41 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch (39.54 KB, patch)
2011-03-10 15:45 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2010-02-04 03:36:10 UTC
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.

Imagine:
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:
org.netbeans.modules.ruby.RubyIndexer$Factory
org.netbeans.modules.ruby.RubyLanguage
org.netbeans.modules.ruby.rubyproject.BootClassPathProvider
Comment 1 Jaroslav Tulach 2010-02-04 03:58:26 UTC
Plus also these classes:
org.netbeans.modules.web.jsf.editor.index.JsfBinaryIndexer
org.netbeans.modules.web.jsf.editor.index.JsfBinaryIndexer$Factory
org.netbeans.modules.web.jsf.editor.index.JsfIndexer$Factory


I've added these classes to whitelist for now (remove them when fixed):
http://hg.netbeans.org/ergonomics/rev/548e1b63f8d7
Comment 2 David Strupl 2010-02-08 02:46:19 UTC
Why is this P2?
Comment 3 Vitezslav Stejskal 2010-02-15 02:22:46 UTC
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.
Comment 4 Vitezslav Stejskal 2010-03-29 14:47:11 UTC
*** Bug 180581 has been marked as a duplicate of this bug. ***
Comment 5 Vitezslav Stejskal 2010-05-14 08:40:48 UTC
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.
Comment 6 rmatous 2010-05-14 09:31:34 UTC
See Issue #180581 where it was many times reported after upgrading to NetBeans v6.8 Patch 1
Comment 7 rmatous 2010-05-14 09:35:58 UTC
Actually not fixing this issue prevents from issuing patches including index changes. P2 for me
Comment 8 David Strupl 2010-05-14 09:36:44 UTC
Radek, cannot we just refrain ourselves from changing the version of indexers for bugfixes that go to patch release?
Comment 9 David Strupl 2010-05-14 09:37:44 UTC
BTW can you please point me to the bugs that required the change? Thanks.
Comment 10 David Strupl 2010-05-14 09:40:56 UTC
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".
Comment 11 rmatous 2010-05-14 10:23:59 UTC
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)
Comment 12 Jaroslav Tulach 2010-06-11 14:53:20 UTC
6.9 is out, we can again use standard bug classification:
http://wiki.netbeans.org/BugPriorityGuidelines

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.
Comment 13 David Strupl 2010-06-11 15:57:39 UTC
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)).
Comment 14 Tomas Zezula 2011-03-07 17:39:49 UTC
Not P2 as the new version of the IDE is installed with new used dir and index version is increased not very often. Anyway I plan to fix it but in some more complex way to also solve the javascript stub problem.
Comment 15 Jaroslav Tulach 2011-03-08 13:00:56 UTC
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[1] in my opinion. Moreover this bug is negatively influencing performance and scalability. As such I believe it shall be P2[2]. 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?

[1] PHP patch was completely broken in 6.8 or 6.7 due to this problem
[2] I understand you do not want to go through waiving process, but that shall not impact the decision about priority.
Comment 16 Tomas Zezula 2011-03-08 13:07:42 UTC
As the index versions do not change for last year the bug affects anything.
Comment 17 David Strupl 2011-03-08 17:07:08 UTC
"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.
Comment 18 Tomas Zezula 2011-03-08 18:12:16 UTC
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.
What Jarda is talking about is that the fix of this bug can be "extended" to also load the indexers on demand which does not save much but also it can be "extended" to do the javascript indexing when it's needed, not when the first project is opened.

It's not P2 from the reason I've described above (no index updated for long time) and also workaround exists.

But I still want to fix it as there are several reports about the javascript indexing and this can be fixed as a part of this issue.
Comment 19 Tomas Zezula 2011-03-10 15:45:11 UTC
Created attachment 106883 [details]
Patch
Comment 20 Tomas Zezula 2011-03-10 15:47:06 UTC
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.
Comment 21 David Strupl 2012-02-24 09:41:27 UTC
Do you plan to integrate this into 7.2?


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