This discussion is archived
10 Replies Latest reply: Apr 22, 2010 1:57 PM by 843804 RSS

Jar downloading and Caching

843804 Newbie
Currently Being Moderated
I have an application that runs on a couple of servers. It's an assessment engine, so you take a test and for each question you download a new jar. Each jar is about 50-500k.

What i don't understand is that once the jars are cached, it still takes a significant amount of time to create the next question on our production environment. On staging and development it is much faster.

Granted the production environment receives production traffic and downloading the jars the first time should be slower, but once the jars are cached, why would it still take a lot of time. Is there still that much interactivity between the servers checking the jars on the server? It seems to me that once the jars are cached from the staging environments and production environments, they should behave practically the same.

Edited by: Brohonimo on Apr 16, 2010 10:54 AM
  • 1. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    The biggest wait comes from

    Reading certificates from 11
    And then there are a bunch of
    Loaded image: Jar: my.jar etc.
    listing in the console.

    There are a bunch of images, but they are cached for crying out loud!
  • 2. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    Here is something curious....

    http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/applet_caching.html#algorithm
    Known Issues

    Caching of the .jar files specified in the manifest's Class-Path variable using Java Plug-in's cache is currently not supported.
    The path specified in the cache_archive must be a relative URL to the applet's codebase. Full URLs are not supported in cache_archive.
    * If you get the "java.io.IOException: Caching not supported for ..." exception, this is because Java Plug-in was unable to get the expiration and last-modification dates for a given JAR file from the web server. If the Java Plug-in cannot get this information, there is no point in caching since the JAR file will be downloaded every time it is used. Even with this exception, however, the applet should work fine. This exception is merely informative.

    Now I specify only the one jar in the archive section of the html, which contains a jar with the classpath to all the necessary jars in the manifest and and Index file as well.

    Each new jar shows up in the java cache and the console itself refers to the jar in the cache....

    Reading certificates from 11 http://blahblahblah.jar | C:\Documents and Settings\dude\Application Data\Sun\Java\Deployment\cache\6.0\20\61ee19d4-232a6a61.idx
    Is it possibly downloading the jar every time to the cache?


  • 3. Re: Jar downloading and Caching
    793415 Pro
    Currently Being Moderated
    Brohonimo wrote:
    Here is something curious....

    http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/applet_caching.html#algorithm
    Oh an applet. It would have been handy to mention that 2 posts ago.

    I would recommend launching it using [Java Web Start|http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp]. JWS provides a much more reliable caching mechanism, and you can go further to take complete programmatic control of the downloads if you wish.
  • 4. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    I assumed the title of the post implied applet caching, but now that it is much clearer great!

    Because our user base is the general population, JWS isn't really practical. It can be very clean, especially for in-house purposes, but for general population use dealing with users who don't have it is a much bigger pain than dealing with users who don't have the plugin. We get millions of users for our applets a year and that would be too radical a change for now.

    Right now I'd like to figure out what the plugin and cache are doing. Is it caching or not?

    Does the class-path variable prevent caching? Can I add the other jars to the html archive and keep the class-path variable (there appear to be benefits from the INDEX.list in the main jar as well....)
  • 5. Re: Jar downloading and Caching
    793415 Pro
    Currently Being Moderated
    Brohonimo wrote:
    ..Because our user base is the general population, JWS isn't really practical. It can be very clean, especially for in-house purposes, but for general population use dealing with users who don't have it is a much bigger pain than dealing with users who don't have the plugin.
    Rubbish!
    1) If the user has the Java plug-in, they have JWS.
    2) deployJava.js can ensure the user has Java (& JWS).
    3) A JNLP embedded applet is indistinguishable from a non-JWS embedded applet.
    .. We get millions of users for our applets a year and that would be too radical a change for now.
    What 'change'? See point 3 above.
    ----------------
    I really feel that Java users are more accepting of JWS than some developers. You sound like you're stuck in thinking that was out of date 5 years ago!
  • 6. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    We tried it. I thought I'd seen the light and then simple in-house testing was fraught with all sorts of peril and problems. People who have java 6 have JWS, but not everyone else. We are trying to move to java 6 for all, but until then its not an option. General users of the internet are stuck in 2004. You have to go with the least common denominator.
  • 7. Re: Jar downloading and Caching
    793415 Pro
    Currently Being Moderated
    Brohonimo wrote:
    We tried it. I thought I'd seen the light and then simple in-house testing was fraught with all sorts of peril and problems. People who have java 6 have JWS, but not everyone else.
    JWS has come standard (co-bundled) with Java, since 1.4.2.
    ..We are trying to move to java 6 for all, but until then its not an option. General users of the internet are stuck in 2004. You have to go with the least common denominator.
    In that case, make sure your app. is powered by fire.
  • 8. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    I can't explain why users with the plugin are unable to run JWS apps, but many can't. The internet is full of examples of why not to use JWS unless you have absolute control over the environment.

    We may try again in the future, perhaps once we can rely on a base of java 6 things will be more streamlined.

    I appreciate your input but its not the answer I am looking for.
  • 9. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    For what its worth...


    Beside the problems we had with people using JWS, I believe this was the clincher

    From http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html

    Java Web Start has support for lazy downloading, but few developers use it. It can be a way to significantly improve the download and startup time in some applications. To effectively use lazy downloading, Java Web Start must be aware which jar to download to resolve a request for a specific resource. Previous versions of Java Web Start required a complex specification of parts and packages to provide this information. Beginning with version 6.0, the same thing can be accomplished using Jar Indexing.

    We do use jar indexing. In any case I tried our our JWS mockup and compared to our current system. Both are caching as they should. And both run with the same performance. The hold up is in the accounting back and forth checking to see if the jar is cached and contains what we need I presume. Since the production environment has so much traffic, it takes a while.
  • 10. Re: Jar downloading and Caching
    843804 Newbie
    Currently Being Moderated
    I have made a discovery.

    I made some changed. I changed the way we were creating images to use getResourceAsStream as recommended here....

    http://java.sun.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html

    I have found however that only if all of the images are in the same jar do you get the benefits of the cache.

    Because we bundle our jars in an "as needed" way, you only have to download a small jar when you need some new images. Images could be in a number of jars in the cache. This used to work great. but it seems now, that there is a great deal of client server searching for the images, or it just doesn't sift through the currently download cache efficiently.

    Interestingly, when I implemented this with Java Web Start, it still was very slow in loading the images, even though there was one jar.