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

[Andrew Su]

Resending, it seems like it didn't get sent properly the first time..

----- Original Message -----
> 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/20110315/0e1cf80e/20110314_mark_netx_running_for_plugin.patch