JDK-6921939 : Applet does not download every other jar file to cache.
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u20
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-02-01
  • Updated: 2010-05-09
  • Resolved: 2010-03-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0-poolResolved
Related Reports
Duplicate :  
JDK-6365587 - Proxy-Connection header sent through tunnel
Duplicate :  
JDK-6921937 - Applet does not download every other jar file to cache.
Relates :  
JDK-2189189 - Proxy-Connection header sent through tunnel
Description
Users of an on-line banking app are getting java exceptions when the applet they choose is loading.
Java is downloading the jar files that the applet has requested into the client's cache.
The java console log shows that only every other jar file is being loaded into cache.
When a method from a jar that does not get downloaded is accessed, the user gets a java exception.

e.g.
network: Connecting https://us.xyz.com/proxy/.../TMSControl.class with cookie...

java.lang.RuntimeException: java.lang.NullPointerException
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source)
        at java.net.HttpURLConnection.getResponseCode(Unknown Source)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
        at sun.applet.AppletClassLoader.getBytes(Unknown Source)
        at sun.applet.AppletClassLoader.access$100(Unknown Source)
        at sun.applet.AppletClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        ...
Comments
EVALUATION See CR 6365587 for updates on this bug.
10-03-2010
EVALUATION The root cause of this bug is CR 6365587.
24-02-2010
WORK AROUND Setting http.keepAlive=false allows the app to work on JDK 5 and 6
16-02-2010
EVALUATION I think the problem is related to proxy + HTTPS + keep alive cache. In HttpClient.java, if I make the following changes to parseHTTPHeader, it works: /* * We're talking 1.1 or later. Keep persistent until * the server says to close. */ if (keep != null) { /* * The only Connection token we understand is close. * Paranoia: if there is any Connection header then * treat as non-persistent. */ keepAliveConnections = 1; } else { keepAliveConnections = 1; // this was 5 originally System.out.println("!!!forcing 1 KeepAliveConn"); } I compared the KeepAliveConnections count between proxy and non-proxy case, and found that in the case where it starts to fail, in the non proxy case keep-alive is set to 1; but when in proxy case, we set keep-alive to 5. With this, the applet loads with proxy too, but it's slower. (probably due to disable to KeepAlive ?) Someone who knows KeepAlive more needs to take a closer look at this. Is it suppose to work with proxy + https ?
16-02-2010
EVALUATION Here is the behavior on the Citidirect case, every alternate jar file is being downloaded to the cache. If you see below in the entry definition.jar did get downloaded and the dpl.jar did not get downloaded to the cache. I checked with the value in the cache as well. This is also however related to proxy being used and not used. If no proxy value is present , all jar files download fine. However when proxy is used, alternate jar files is downloaded. Any trouble shooting tips to this? Customer sees this in all versions of JDK 5 and later. Does not see the behavior in JDK 1.4.2. The log files are present in \\jpsesvr.sfbay\jpse-US1\rp203170\windows\Citibank-6921939\logs\Feb9\JDK5 network: Connecting https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/definition.jar with proxy=HTTP @ webcache.sfbay.sun.com/129.146.11.108:8080 network: Connecting https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/definition.jar with cookie "CLS_SessId; LangID=en_US; ClientVM=JPI; JSESSIONID=0000a2JMAqc4lWorqnjviI9aE3y:12qgndhro; SWID=888f6668697171716b69b49da6978d8b56; SPECIAL_SVC_NEEDED=TRUE; UserBinding=0-0; WSSESSID=0000W10KUyrXu75QIexQmT1UzeP:12adn2i5e; LOGIN_METHOD=CITIDIRECT; SUINFO=768674928d6363636364af98a192888651; CasaCoAuthCookie=95504d7f4a4e4f4a4b47517c534d474e7d4a7e477c4c7f7b474b4a4b4e527f7c4a51514b4c97966d63676a6d5f5d966a71484a4b5353534d4b967f88796f6d26; CLS_SessId=OBF:1fa91ldy1fgi1g8o1lry1ls01g921fgc1ldk1f8db2sFh1Xjxhx0pjvFP" basic: Downloading https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/definition.jar to cache basic: encoding = null for https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/definition.jar basic: Cached file name: definition.jar-38db4fe6-75ebbb32.zip basic: httpCompression = true network: Connecting https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/dpl.jar with proxy=HTTP @ webcache.sfbay.sun.com/129.146.11.108:8080 network: Connecting https://uat31.citidirect.citigroup.com/proxy/clsswd01.nam.nsroot.net/clsjret/lib/dpl.jar with cookie "CLS_SessId; LangID=en_US; ClientVM=JPI; JSESSIONID=0000a2JMAqc4lWorqnjviI9aE3y:12qgndhro; SWID=888f6668697171716b69b49da6978d8b56; SPECIAL_SVC_NEEDED=TRUE; UserBinding=0-0; WSSESSID=0000W10KUyrXu75QIexQmT1UzeP:12adn2i5e; LOGIN_METHOD=CITIDIRECT; SUINFO=768674928d6363636364af98a192888651; CasaCoAuthCookie=95504d7f4a4e4f4a4b47517c534d474e7d4a7e477c4c7f7b474b4a4b4e527f7c4a51514b4c97966d63676a6d5f5d966a71484a4b5353534d4b967f88796f6d26; CLS_SessId=OBF:1fa91ldy1fgi1g8o1lry1ls01g921fgc1ldk1f8db2sFh1Xjxhx0pjvFP" basic: httpCompression = true
09-02-2010
EVALUATION I can reproduce it. Debugging the issue, will update as I make progress.
02-02-2010