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

[Andrew Su]

> > 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.)

Patch updated to work with head.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20110315_mark_netx_running_for_plugin_v2.patch
Type: text/x-patch
Size: 7592 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110315/24d2807f/20110315_mark_netx_running_for_plugin_v2.patch