[RFC][Icedtea-Web]: Fix bug where you can clear cache while plugin is in use.

[Andrew]

Hi,

   This is a fix to an issue where you can use javaws -Xclearcache to 
remove the cache directory while an applet is running through the 
browser. This causes the applets to fail to load and other disastrous 
things to happen.

To fix this I moved Launcher.markNetxRunning() and 
Launcher.markNetxStopped() to JNLPRuntime class. I believe these are 
closely related to the "runtime" of the plugin and/or javaws, so it 
makes sense to put them there.

We call JNLPRuntime.markNetxRunning() before we launch something, 
(application or applet). Adding a check to markNetxRunning() so that if 
we have already been marks, just continue. Since we are marking it as 
running, we also want to mark it as not running when we shutdown the 
JVM. The call to adding the shutdown hook for markNetxStopped() is moved 
to the end of the markNetxRunning method.

2011-03-14  Andrew Su <asu at redhat.com>

         * netx/net/sourceforge/jnlp/Launcher.java:
         (launch): Mark NetX as running before launching apps.
         (launchApplication): Removed call to markNetxRunning().
         (markNetxRunning): Removed method.
         (markNetxStopped): Removed method.
         * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java:
         (fileLock): New private static field.
         (markNetxRunning): New method to indicate NetX is running.
         (markNetxStopped): New method to indicate NetX has stopped.

Minor Concerns:
   - Is it possible to get a race condition when calling markNetxRunning 
in JNLPRuntime. Since this now affects the plugin and not just javaws, 
this might be called multiple times by different threads? if so, I would 
synchronize it and since subsequent calls will instantly return if the 
first call succeeded in getting the lock, so there won't be much 
performance hit.
   - We try to attain the lock but fails if javaws -Xclearcache is in 
progress, as calling clear cache it holds an exclusive lock (which is 
right). However we would proceed as normal (by normal I mean it can be 
downloading new jars for applets and such) without having a lock to 
indicate that we are running. Which can still lead to the problem we are 
trying to fix. To remedy this we should either make it wait until the 
lock becomes free. (and thus we need to synchronize it if this can be 
called by multiple threads.)

Questions? Comments? Concerns?

Cheers,
   Andrew
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20110314_mark_netx_running_for_plugin.patch
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110314/9a0deb53/20110314_mark_netx_running_for_plugin.patch