RFC: Netx - implement -Xclearcache command line option

[Omair Majid]

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

Thanks,
Omair