[RFC][Icedtea-Web]: Fix bug where you can clear cache while plugin is in use.
asu at redhat.com
Mon Mar 14 15:11:01 PDT 2011
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>
(launch): Mark NetX as running before launching apps.
(launchApplication): Removed call to markNetxRunning().
(markNetxRunning): Removed method.
(markNetxStopped): Removed method.
(fileLock): New private static field.
(markNetxRunning): New method to indicate NetX is running.
(markNetxStopped): New method to indicate NetX has stopped.
- 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
- 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?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the distro-pkg-dev