Bug 228318 - Netbinox caches should not crash product if findInstallationArea() changes
Netbinox caches should not crash product if findInstallationArea() changes
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Netigso
7.4
PC Linux
: P2 (vote)
: 7.4
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-05 23:30 UTC by stoto79
Modified: 2013-04-28 02:18 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The tests that seem to demonstrate the failures (7.52 KB, patch)
2013-04-15 10:15 UTC, Jaroslav Tulach
Details | Diff
Tests, implementation and note in arch.xml (26.22 KB, patch)
2013-04-15 14:51 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description stoto79 2013-04-05 23:30:43 UTC
See Oracle bug 16450627: INVALIDEXCEPTION :CANNOT START ORG.ECLIPSE.EQUINOX.COMMON  .

In the above bug JDev, a product running the Netbinox platform, crashes if its NB caches are corrupted. In the above case, it crashed because the value of 'netbeans.dirs' was different at the time the cache was built and the time the product was ran. The system property 'osgi.install.area', which is equal to the root that every cache entry will be made relative to, is computed by NB as the most common prefix of all entries of 'netbeans.dirs', the caches gave us back the wrong jar locations, and JDev crashed. 

The resolution for that bug was to invalidate the caches from the JDev side. But since finding all cases where the cache should be invalidated is a such a ad-hoc, error-prone process, the caching mechanism should be forgiving enough and not crash the entire product. NB caching is an optimization, so--ideally anyway--failure in it should never crash our product, but possibly only run slower.
Comment 1 Jaroslav Tulach 2013-04-12 10:46:08 UTC
The puzzler that keeps me busy is: Should the system detect when just the top most directory changes or any change to the list of clusters?

For the JDev case, this is probably the same as addition of new clusters caused the common installation prefix to change. However for NetBeans, this would not be the case. All clusters are usually placed under directory "netbeans" and adding new ones won't change the common installation prefix at all.

The first approach could invalidate just the cache from core.netigso module (however that is unlikely correct, other files, for example containing list of modules have probably changed as well).

The latter approach requires us to store a checksum file (recording information about cache at the time of creation). There currently is such checksum file, but only in user directory and moreover it contains a bit too much information which might now be after installation (like time stamps of .lastModified files in each cluster).
Comment 2 Jaroslav Tulach 2013-04-15 10:15:11 UTC
Created attachment 133499 [details]
The tests that seem to demonstrate the failures
Comment 3 Jaroslav Tulach 2013-04-15 14:50:29 UTC
Requesting API change review, as I am about to add new file into the cache which may affect installer.
Comment 4 Jaroslav Tulach 2013-04-15 14:51:19 UTC
Created attachment 133505 [details]
Tests, implementation and note in arch.xml
Comment 5 Jaroslav Tulach 2013-04-22 06:36:41 UTC
Unless there are objections, I'll integrate the change tomorrow.
Comment 6 Jaroslav Tulach 2013-04-23 11:04:41 UTC
ergonomics#997ae78bd4b6
Comment 7 Quality Engineering 2013-04-28 02:18:12 UTC
Integrated into 'main-golden', will be available in build *201304272301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/997ae78bd4b6
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #228318: Store relative paths of clusters with respect to common shared prefix


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