FULL PRODUCT VERSION :
Java Plugin 1.4.1_03

FULL OS VERSION :
Windows XP
Windows 2000
Windows ME
Windows 98
Windows NT

A DESCRIPTION OF THE PROBLEM :
Ours is a Internet banking site that has 2 servers and it uses load balancing to hit any of the servers on client request. We use a signed applet that is Microsoft JVM enabled i.e it gets downloaded (sticky caching) and works perfectly on applet version changes(downloads new version ). Lately we were tring to enable it for SUN JVM (1.4.1_03)and that is where our problem starts. SUN JVM downloads the applet perfectly and suffixes the name of the applet with some numbers\characters on its own. No problems with that. But if the request that downloads the applet hits the different server, it starts downloading the applet again. That means we have two applets for different servers.
The request URL is same for both of them. We go thru the same url and it is only later that the load balancing comes into picture.
Since the cache_version tag does not work properly(known bug in SUN JVM) so we depend on the content size and date stamp of the applet. Both things are same for the servers.
We tried to syncronize the server dates as well but all in vain.

REPRODUCIBILITY :
This bug can be reproduced always.
(Incident Review ID: 193238) 
======================================================================

N/A

The cached jar file is tied to the URL from where it was downloaded. When the applet is downloaded from a different host, the url for the jar file also changes and it doesn't match the url recorded in the cached jar. Therefore the jar file is downloaded again
 xxxxx@xxxxx  2003-09-16
----------------------------------------

The customer is using DNS load balancing e.g. if you have 2 http servers with
the same content you can spread the load between them by configurating your DNS
server to resolve the host name to alternative addresses of each server. This is 
causing plugin to download and cache jar files for each server even though the 
url is the same.

The key used to lookup the url in the cache is constructed with the jar filename
and the java.net.URL.hashCode. java.net.URL.hashCode will return different 
hashCode's for identical URL objects that resolve to different addresses.

 xxxxx@xxxxx  2003-11-03
----------------------------------------

We have a similar setup in our signed applet, except we have 
FOUR web servers that are using Syscos Distributed Director 
to do IP spraying (to 1 of 4 IP addresses) from the same URL.
Were using HTTPS to get to the applet. 

The evaluation from 9/16/03 says that its tied to the url, do 
you mean the URL object is used is the caching algorithm ?

If URL is used to determine the caching algorith, IP address is 
part of the URL object. Based upon our research, the first 
number following the jar file name is based upon the URL 
obect. The second number is purely random (from what we 
can tell).

This is a MAJOR MAJOR problem for our apllication as users 
have to eventually download 4 versions of each jar file.

Prior to usingJRE 141_01 our application was using JRE 130C 
and this setup was NEVER a problem. Users only downloaded 
1 version of each jar file no matter what server they hit with 
the same url.

Is this bug fix included in 1.4.2_07? 
Just checking since we have discovered this issue related to our new image (XP SP2 with Sun JVM 1.4.2_05