Community
Participate
Working Groups
Build RC2 As shown in bug 34574, if a jar (or another library) is not on the classpath when it is changed, we don't detect that the corresponding index should be recomputed if this jar is added to the classpath later on.
Fix would consist in 2 parts: - delta processor would remove the in-memory index when detecting a change to a jar or library folder that is not on the classpath - index manager would need to remember the timestamp of the jar or library folder for each index. It would use this timestamp to determine if the jar or library folder needs to be reindexed.
Unless PDE works around this issue (unlikely), we should fix this providing we have the 2 portions of the fix (only if we do). Without fixing this defect, we have a regression compared to 2.0, where indexes would only be inconsistent until the next session. Indeed, on next session, the eager index consistency check would reject the old JAR index. Will candidate it for RC3. Kent, can you investigate a fix for dealing with timestamps ?
Actually, the change in the delta processor would be too costly. A better change would be in SetClasspathOperation: when detecting that a root is removed, it should remove the in-memory index.
If the PDE bug is not fixed (and Jerome doesn't put in a patch to delete the in- memory index), then we will have a problem with replaced jar files if the first request of all future sessions for the index is a search job. If the first request of the next session for the index is a rebuild job then the index will be recreated, just as it was in 2.0.
If the replacing JAR is close enough (same entries), we will not think we need to recreate it, though references maybe totally different. The timestamp idea would elegantly solve this. Also, for the in-memory cleanup, as soon as the JAR/lib is no longer referenced from any classpath, it should be removed from the in-memory table; but kept on disk, so that if switching JDKs or similar things, then it would get reopened from disk rather than being fully recreated (cleanup on disk only occurs on shutdown). Index file opening should check for dirty-ness and timestamp of matching lib.
Got approval for RC3.
Solution was finally to remove both the in-memory index and the on-disk index if the jar is not referenced on any classpath.
Verified.
