RFC: Netx - implement -Xclearcache command line option

[Deepak Bhole]

* Omair Majid <omajid at redhat.com> [2010-10-05 15:42]:
> On 10/05/2010 03:32 PM, Deepak Bhole wrote:
> >* Omair Majid<omajid at redhat.com>  [2010-10-05 14:45]:
> >>On 10/04/2010 03:17 PM, Omair Majid wrote:
> >>>On 09/30/2010 05:27 PM, Deepak Bhole wrote:
> >>>>* Omair Majid<omajid at redhat.com>  [2010-09-30 16:50]:
> >>>>>On 09/30/2010 04:32 PM, Deepak Bhole wrote:
> >>>>>>* Omair Majid<omajid at redhat.com>  [2010-09-30 16:10]:
> >>>>>>>Hi,
> >>>>>>>
> >>>>>>>I posted this patch way back in 2009, but it looks like it got
> >>>>>>>lost/ignored.
> >>>>>>>
> >>>>>
> >>>>>Ok, turns out it was my fault: just noticed
> >>>>>http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006666.html.
> >>>>>
> >>>>>Somehow it slipped off my radar.
> >>>>>
> >>>>
> >>>>Doh. Glad it was re-visited. I doubt the issue will be encountered, but
> >>>>we might as well fix it instead of waiting for a bug report.
> >>>>
> >>>>>>>On 07/30/2009 05:18 PM, Omair Majid wrote:
> >>>>>>>>The attached patch adds the option -Xclearcache to Netx.
> >>>>>>>>
> >>>>>>>
> >>>>>>>Which (and I neglected to explain this last time) makes javaws clean
> >>>>>>>out its cache by deleting the contents of ~/.netx/cache/
> >>>>>>>
> >>>>>>
> >>>>>>Hmm, what happens if I have another netx app running and javaws is
> >>>>>>called
> >>>>>>with -Xclearcache? AFAIK the code has no provisioning to detect if a
> >>>>>>cache file has been deleted, and to re-download it... does it?
> >>>>>>
> >>>>>
> >>>>>As far as I can tell, very bad things (not eating babies kind of
> >>>>>bad, but still...). Depending on the exact timing either the VM will
> >>>>>crash or a java Exception might be thrown. If the JVM has opened the
> >>>>>(missing) jar earlier and and wants to open it again to load
> >>>>>additional classes the VM will most probably crash. Otherwise javaws
> >>>>>simply wont be able to find the needed jar and will fail to start.
> >>>>>
> >>>>>I suppose I could make some sort of global application lock to stop
> >>>>>any other javaws instances from starting while -Xclearcache is
> >>>>>running and to make sure -Xclearcache does not start if any other
> >>>>>javaws applications are running.
> >>>>>
> >>>>
> >>>>It would be hard to set up a locking system that can handle odd cases
> >>>>like crashed application, multiple instances of same app., etc.
> >>>>
> >>>
> >>>Yeah, you are right. I thought about it for a bit, and I dont see a
> >>>simple way to make it work using locks.
> >>>
> >>>>Easiest way I think is to execute jps -l and see if there is more than
> >>>>one instance of net.sourceforge.jnlp.runtime.Boot. If there is, refuse
> >>>>to run with -Xclearcache. I am not as worried about the 'don't start
> >>>>while -Xclearcache is running' case, as there is a far smaller window
> >>>>where things can go wrong. Plus if they do, it will be right away (as
> >>>>opposed to an already started app that has modified data, crashing).
> >>>>
> >>>
> >>>That's a great idea! Unfortunately I dont think we can rely on jps. jps
> >>>is part of the JDK as opposed to the JRE - we can not be sure that users
> >>>have it on their machine. I tried looking into the sources for jps to
> >>>find out how it works. The JVM creates /tmp/hsperfdata_$USER/$PID files
> >>>which contain the information that jps can parse and display. The files
> >>>are in a binary format so parsing it is not trivial (and the file format
> >>>is not guaranteed to be final). I am going to dig around a bit to see if
> >>>there is any other simple solution to this
> >>>
> >>
> >>I am attaching the updated patch. This one uses an alternate
> >>implementation based on file locks (exclusive and shared). A normal
> >>javaws process acquires a shared lock on /tmp/$USER/netx/instance
> >>during startup (when an instance of Launcher is created), and
> >>releases the lock when the JVM shutsdown. Multiple javaws processes
> >>can share the lock and run simultaneously.
> >>
> >>The javaws process that is trying to clear the cache checks for the
> >>file and tries to acquire an exclusive lock. If it succeeds, it goes
> >>ahead and clears the cache; otherwise it prints out an error to the
> >>user and exits.
> >>
> >>Thoughts?
> >>
> >
> >Just one minor thing... for the plugin, we use
> >/tmp/icedteaplugin-$user for data storage. For the above, can you please
> >change it to /tmp/netx-$user for consistency?
> >
> 
> Sure. But netx is already using /tmp/$USER/netx/locks/ for creating
> single instance locks (most of the paths netx uses are be defined in
> JNLPRuntime - though there are a few entries missing [like
> ~/.netx/pcache and ~/.netx/cache]). Do you want me to fix that as
> well?
> 

Ah okay nevermind then. I wasn't aware that the dir was already being
used for something else. Keep it as it is then I'd say. At some point in
the future we should consolidate both plugin and netx to use a single
dir. But that is for another time.

Cheers,
Deepak

> >Rest looks good! Assuming you have tested this, please go ahead and
> >apply to HEAD and all active branches.
> >
> 
> Thanks for the review!
> 
> Cheers,
> Omair