Bug 166254

Created attachment 82972 [details]
screenshot

Strange, but if it's reproducible only on one platform .. I would say we can live with that for RC1 ... would be nice to
find root cause and fix for RC2

Hm... looks like I can reproduce it as well on both Solaris x86 and sparc, was not able to reproduce on Windows.

Workaround that helps (I don`t know why) is  
$ rm ~/.netbeans/6.7rc1/var/cache/lastModified/soa2

SOA is installed into installation directory. Just after SOA installation and restart the timestamps are:
2009-05-29 22:02:18.444541000 +0400 (~/netbeans-6.7rc1/soa2/.lastModified)
2009-05-29 21:59:10.930217000 +0400 (~/.netbeans/6.7rc1/var/cache/lastModified/soa2 )
2009-05-29 22:02:19.816460000 +0400 (~/.netbeans/6.7rc1/.lastModified)

Autoupdate does know nothing about <userdir>/var/cache/lastModified. 
Additional manual touching of .lastModified file (both in install and usedir) has very strange affect: 
- closing IDE, touching those files and starting it again - SOA shown as not installed.
- closing IDE again, touching those files again and starting IDE again - SOA shown as installed.
Unlikely the AU issue - reassigning to platform for further evaluation.
Maybe some wrong magic in o.n.bootstrap/src/org/netbeans/Stamps.java (but also maybe AU should handle that somehow...)

These timestamp manipulations are Yarda's; I have little idea how it is supposed to work and what to do when it doesn't.

Still unable to reproduce on x86 for latest truck build.
SPARC affected as described.

Product Version: NetBeans IDE Dev (Build 200906010201)
Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b15
System: SunOS version 5.11 running on x86; UTF-8; en_US (nb)

Ok, this issue is considered as a stopper for RC2/FCS

AutoUpdate shall not care about $userdir/var/cache/lastModified/cluster at all. Something is wrong in the platform.

There were few problems in the Stamps code and I addressed two of them in ergonomics#ef2526558afb. However I am not 
sure if it helps this particular problem. It shall. Please verify in 
http://deadlock.netbeans.org/hudson/job/ergonomics/177/

I'll likely have no time to do "the paperwork" tomorrow. But it shall be simple. To merge to release67 just:
hg pull -r ef2526558afb http://hg.netbeans.org/ergonomics/
hg merge
hg ci -m "Merge of #166254"
hg push

Yarda, thanks for your help. We'll verify that tomorrow and I'll ask Tonda for transplate into release67.

... and keep it open for NB 6.7 

It would be a pull, not a transplant operation.

RC2

RC2

Michael, 
this issue hasn't been ported to release67 yet, as I know. 

>RC 2
Does it work there ?

RC2 checked today is free of this issue so I assumed it fixed as planned.

Looks like setting of "Force install into shared directories" make
sense to reproduce this issue.

Integrated into 'main-golden', will be available in build *200906031401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ef2526558afb
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #166254: Don't create any lastModified info for non-existing clusters. Also reset the result for each cluster to isolate it from the influence on previous results.

http://hg.netbeans.org/release67/rev/ef2526558afb

Thanks a lot Jarda!

Issue was not fixed completely. Installation looks workable now but
after uninstallation IDE shows lot of exceptions like:
ZipException: error in opening zip file;
ClassNotFound: org.netbeans.modules.xml.schema.abe.action.PaletteCustomizerAction;
MissingResourceException.

Again only SPARC platform affected.

I'd suggest to report another bug against installer. The uninstall problem is something unrelated to the P1 bug I 
fixed and I doubt it classifies for P1 priority. Better to track it in separate issue.

Otherwise I am glad to hear that the cache problem is solved.

Original title of this issue was not changed -- it's about installation and uninstallation.
But if you prefer to keep them separated -- not a problem.

The fix does not work for me - I`ve tried RC2 build 2009-06-04_01-12-31 and SOA is still in "Available" list after its 
installation.
What I did :
0) Clean ~/.netbeans
1) Use "full" bundle, install as user all IDE features, no servers.
2) Run IDE, opened Tools->Plugins, reload catalog, install SOA
3) Restart, again opened Tools->Plugins. SOA is still in "Available" plugins list.
No exception thrown in the log.

I think it might be RANDOM.

SOA and XML Schema

I just tested the behaviour on my SunRay and it worked without a problem.

I was able to reproduce as well using host provided by Dmitry. I used same
shared homedir (so same jdk and other staff) as with other host, but result
vary from host to host and stable on each host so I don't know is this really
RANDOM or just depends on yet unknown reasons.

I still have not managed to reproduce the problem. But I found another issue that might cause it. Please try again 
with ergonomics#894fdac0c8f3

Jarda, could you please attach new <nbdir>/platform10/lib/boot.jar file with this fix? 
It will help to check the fix in less time...

Created attachment 83345 [details]
boot.jar which does not include non-existing clusters in all-checksum.txt

Dmitry, if you are able to reproduce the problem, can you please debug Stamps class and find out why the caches are 
not invalidated when the list of clusters changes (this shall invalidate the content of all-checksum.txt file) or when 
something new gets installed into existing cluster (this shall change timestamp of its .lastModified file)?

The issue is still reproducible with the attached boot.jar, I`m debugging Stamps at the moment...

Thanks in advance for help. The puzzle imho is why method private File file(String cache, int[] len) at line 160-190 
returns non-null.

There is some mess with timestamps. 

File f = new File(System.getProperty("user.home"), ".lastModified");
long diff = System.currentTimeMillis() - f.createNewFile().lastModified();

On my Windows system diff is either 0 or small positive value. 
On Linux system with $HOME located on the current disk drive the diff is small positive value.

On Solaris (Sparc,x86) and Linux system with HOME mounted via NFS the "diff" is negative value. Really weird...
At least UpdaterDispather.touchLastModified() should be fixed - I`m working on that. 
And likely Stamps.discardCachesImpl() should be fixed as well...

UpdaterDispatcher fixed in 
http://hg.netbeans.org/core-main/rev/a67c224dfb8d
I haven`t touched Stamps.

In case installation is done on the local partition (e.g. in /tmp) this issue is not reproducible (I`ve tried pure RC2) 
as well as 166569.

So the bug likely comes from the mistiming of the desktop system and the server which $HOME partition is stored at.

*** Issue 166569 has been marked as a duplicate of this issue. ***

I am not sure, but probably there is no need to fix Stamps. Stamps only read .lastModified file's time, never write it 
down. Hopefully the problem disappears just after your a67c224dfb8d fix.

Unfortunately it does not disapper even with a67c224dfb8d.

To reproduce the issue, likely it is enough to set desktop time, say, one hour before the time set on the NFS server 
(with respect to time zones) which the home partition is been stored at.

Hasn't been fixed in release67 yet.

After a discussion with jtulach - we agreed on that this is not a stopper for NB 6.7 .

Jindra will help me emulate the problem. However it seems that there needs to be some misconfiguration between the 
desktop and server for the bug to happen. Do I also need to have installation on server and userdir locally? Or is it 
possible to reproduce the problem while both userdir and installation are on the same (nfs) disk?

> Do I also need to have installation on server and userdir locally? 
> Or is it possible to reproduce the problem while both userdir and installation are on the same (nfs) disk?

Hard to say... I have $HOME partition on NFS and installed NB on it. So both userdir and installation are on this 
partition.

I managed to simulate the problem. My changes done in main#0db4fcae704a seem to fix it. What are their other 
implications remains to be seen.

Integrated into 'main-golden', will be available in build *200906110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/a67c224dfb8d
User: Dmitry Lipin <dlipin@netbeans.org>
Log: Issue #166254 Plugin installation/deinstallation work badly on Solaris SPARC

verified with 200906110201.

Issue 166569 still reproducible, so we need to reopen this
issue or clear "duplicate" status from other one.
Looks like theory about same cause for both issues is not
correct unfortunately.

As nobody answered, doing by myself.
Issue 166569 marked as duplicate of this issue and still reproducible. Reopen.

This issue gets pretty long and fuzzy. Some problems got fixed, some may remain, but I'd rather reopen the duplicate
issue 166569 or create some new ones then continue in this one. I hope this is acceptable to all sides.