Browse Prior Art Database

Controlling Webserver Demand for Java Applets for Browsers Supporting Java 2 JRE

IP.com Disclosure Number: IPCOM000010567D
Original Publication Date: 2002-Dec-18
Included in the Prior Art Database: 2002-Dec-18
Document File: 3 page(s) / 46K

Publishing Venue

IBM

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 3

  Controlling Webserver Demand for Java Applets for Browsers Supporting Java 2 JRE

  Disclosed is a design for controlling the updating of cached Java* ARchive (JAR) files on a web browser such as Internet Explorer* or Netscape*, which has a Java 2 Runtime Environment (JRE) installed. In the normal mode of operation, JAR files may be stored indefinitely on the client machine. The JRE will automatically check to see if these cached JAR files may be updated. However, if an update is available, thousands of clients may try to update their JAR files simultaneously, causing the network or web server to be overwhelmed. This design will allow administrators to control the update of these JAR files.

Sun Microsystems, Inc. and IBM have implemented a caching mechanism in their respective JRE plug-ins for web browsers such as Internet Explorer and Netscape Navigator. This caching mechanism is for storing JAR files on the client workstation so the JAR files do not have to be downloaded each time the browser points to an HTML page that runs a Java Applet. This mechanism is commonly referred to as the "Sticky Cache".

In the default mode of operation, no file version is specified in the HTML. The JRE will query the web server for file versions, to determine if upgrading is necessary. In this model, the JRE will always send queries over the network whether or not the files have been upgraded, and if an upgrade is necessary, the updated JAR files will be downloaded. A second model has been implemented in the JRE, to help reduce the extra network traffic generated by these queries. For JAR files to get installed into the "Sticky Cache", HTML tags are used to specify the jar file name and the version of the jar file. When a new version of the Java applet is placed on the web server, the jar file can have a higher version number which then tells the JRE to download the new jar file and update the version number. This makes it unnecessary for the JRE to query the web server for file versions, since the file versions are kept in the HTML file. If an upgrade is necessary, the JRE will always request the updated JAR files from the web server.

This can present a problem if, for example, a company has several thousand web users and the jar files themselves are large. If an upgrade is installed on their web server, then all users could try to upgrade at once, which could result in the web server being overwhelmed with download requests for the updated JAR files. This could cause large usage spikes on their network.

Our solution will keep track of our file versions separately from the mechanism used by the JRE. This is done by having all users point to an HTML page that runs a small Java applet that compares the archive version list kept on the client machine against a similar list kept on the web server. This HTML page contains additional applet parameters that tells the applet what to do in case there is a new version available on the web server. When this app...