views:

375

answers:

4

Hello world, I'm having a problem with a Java applet I've deployed that is refusing to be cached in the jvm's "sticky" cache (or by the browser). For some reason every time a user loads the page this applet is on, the jvm re-downloads the jar file from the server which causes a long delay.

The webpage containing the applet is being accessed via the internet, so according to Sun's Java applet documentation I'm using an <applet> tag rather than an <object> or <embed> tag.

Any help debugging or identifying the problem would be much appreciated.

Below is the full applet tag I'm using:

<applet alt="Scanning Applet failed to load" archive="scanning.jar"
        code="scanning.scanlet.class" codebase="/java/" codetype="application/java"
        height="30" mayscript="True" name="scanlet" width="200">
    <param name="domain" value="192.168.12.23" />
    <param name="publishName" value="scan_attachment" />
    <param name="publishURL" value="http://192.168.12.23/draft/update/52" />
    <param name="curURL" value="http://192.168.12.23/draft/edit/52" />

Your browser is unable to process the Java &lt;APPLET&gt; tag needed to display this applet
<br />
One solution would be to download a better web browser like
<a href="http://www.mozilla.com/firefox"&gt;Mozilla's Firefox</a>

</applet>
+1  A: 

This official article describes how you can change your APPLET tag to increase caching:

http://java.sun.com/products/plugin/1.3/docs/appletcaching.html

Jon
Jon, thx for the quick response, unfortunately I've been up and down that official document. According to it, since I was just using the archive attribute, I should have been getting some sort of fallback browser level caching even without the new cache_* attributes, right?
John Fogerty
At any rate, after adding the cache_* attributes to my applet tag as follows, the applet is still refusing to be cached by the jvm:<applet cache_archive="scanning.jar" cache_option="Plugin" cache_version="1.0" code="scanning.scanlet.class" codebase="/java/" codetype="application/java" height="30" mayscript="True" name="scanlet" width="200"> ...same params, etc.. </applet>
John Fogerty
Well, this "fallback browser level caching" is still done by the JVM and is usually the problem.
ArtemGr
A: 

Personally I solved the caching issues by using cache_archive and cache_version parameters docummented at http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/applet_caching.html

My cache_version is based on the actual file modification date, e.g.

val archive = libs.map("/" + _.getPath).mkString (", ")
val version = libs.map(_.getUpdated / 1000 / 20 - 59281420).mkString (", ")

and to work with MSIE it looks as:

if (msie) {
  cms write <OBJECT
    classid="clsid:CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA"
    codebase="http://java.sun.com/update/1.6.0/jinstall-6-windows-i586.cab"
    width="100%" height="100%">
    ...
    <PARAM name="cache_archive" value={archive}/>
    <PARAM name="cache_version" value={version}/>
  </OBJECT>
} else {
  cms write <applet ...
    cache_archive={archive} cache_version={version}></applet>
}
ArtemGr
John Fogerty
Does it happens only to you or does it happen to all (some of) the users of the web site? If the former, then might it be that the Java Plugin on your computer can't cache the file for some reason? On Windows Java Plugin have an option to cache in the browser cache, in which case the browser cache limitations might apply (you can see what is cached via the control panel, BTW); on UNIX ~/.java/deployment/ folder is used for caching, ~/.java/ should be writeable etc.
ArtemGr
It happens to everyone who uses the site :[. On Windows machines, I've looked thru the Java Control Panel and only 'caching' settings I can find are under Temporary Internet Files->Settings. Those settings all looked good though. I've also looked under Temporary Internet Files->View to verify that the .jar file in question is not present in the cache :[
John Fogerty
I've enabled logging and tracing via the Java Control Panel->Advanced->Debugging and I'm getting many iterations of the following message: network: Cache entry not found [url: 192.168.12.23/java/scanning.jar, version: 1.0]
John Fogerty
I've been examining a working example of a jar-based applet at: http://java.sun.com/docs/books/tutorial/uiswing/components/applet.html. For this working applet, java console prints out: network: Downloading resource: http://java.sun.com/docs/books/tutorialJWS/uiswing/components/ex6/TumbleItemProject.jar Content-Length: 60,507 Content-Encoding: null ...network: Wrote URL http://java.sun.com/docs/books/tutorialJWS/uiswing/components/ex6/TumbleItemProject.jar to File F:\Documents and Settings\Administrator.STFUNATOR\Application Data\Sun\Java\Deployment\cache\6.0\29\1055419d-13a80961-temp
John Fogerty
The jvm debugging printout for my applet looks very similar, but it never prints out the line starting with: "network: Wrote URL ... to File ..." which is where the jar file gets written to the jvm's local disk cache. For some reason that just never happens for my applet..
John Fogerty
Is "192.168.12.23/java/scanning.jar" the correct location of your JAR? Have you tried opening the URL in browser (the browser should see the jar and make you an offer to download it...). I wonder why the URL doesn't start with "http://" as it should. 192.168.12.23 looks like the local network to me (e.g. not the Internet). You serve your site on the local network?Also see if adding codebase_lookup="false" helps (http://forums.sun.com/thread.jspa?threadID=5342008), though it's not directly related to caching.
ArtemGr
That is the, verified, correct location of the jar in my testing env, where I'm trying to debug this problem. Will try the codebase_lookup=false, thx
John Fogerty
codebase_lookup="False" did not seem to change anything. The jar file is still not being cached. This is a signed jar file, could that affect the caching in some way?
John Fogerty
My signed jars are cached okay. I suspect the use of IP instead of dns name is the culprit. I suggest you do a minimal testcase: two files, html and a "Hello world" jar, which you can publish, - and then see how this test setup works from different hosting providers, e.g. whether it's cached from a normal hosting provider and then whether it's cached from 192.168.12.23.
ArtemGr
+1  A: 

I had the very same problem and found a trick that need to be applied server side. It seems that jars aren't cached if their mime type is incorrect. Please check your server reply using the application/java-archive mime type.

Another problem I found is related to a specific jar. My archive parameter was listing many jars, but only a few were cached. I found that all jars upto a specific one where cached, all remaining jars weren't cached at all. While loading applet, I pressed "5" in its java console and found this message just after the last cached jar: cache: signed entry missing from jar . I still don't know what is wrong with this file, but I moved that jar at the end of the archive parameter list. This "fixed" the problem.

eppesuig
A: 

For me I had to remove the Jar files from the Archive tag and just have it in the cache_archive parameter, and specify the versions that way it doesn't piggy back to the server for last modified date

Fixed it in firefox for me

Patrick Ecord