JDK-5081705 : When JRE cache cleared, applet fails to play video through proxy ser
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-08-02
  • Updated: 2017-07-20
  • Resolved: 2017-07-20
Related Reports
Relates :  
JDK-5075841 - HttpURLConnection through a proxy sometimes fails when keepalives are enabled
Description
Name: kcT146510			Date: 08/02/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta3-b60)
Java HotSpot(TM) Client VM (build 1.5.0-beta3-b60, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Pro Sp1

A DESCRIPTION OF THE PROBLEM :
1) Clear cache for JRE 1.5 beta 3
2) Run this applet at: http://cjs.sfbay.sun.com/getjava/videobanner/v1.html
3) The applet doesn't run the first time it loads. But if you press reload couple of times or run it again when you restart the browser (applet already cached), the applet works.


The applet starts two threads: the main applet thread and a download
thread. Within both threads a download process is initiated: within the
applet thread the start-up GIF is downloaded, while within the download
thread the video stream is downloaded. Both threads use pretty similar
code for downloading:

Applet Thread:

         src_url  = new URL(getCodeBase(),getParameter("src")+".gif");
         urlcon   = src_url.openConnection();
         urlcon.setUseCaches(false);
         data_len = urlcon.getContentLength();
         dis      = new DataInputStream(urlcon.getInputStream());


Download Thread:

         src_url  = new URL(getCodeBase(),getParameter("src"));
         urlcon   = src_url.openConnection();
         urlcon.setUseCaches(false);
         data_len = urlcon.getContentLength();
         bis      = new BufferedInputStream(urlcon.getInputStream());

The download process of the applet thread is initialed always first
and always succeeds with no problems. However, under the second
download process (for downloading the video stream) fails UNDER
SPECIAL CONDITIONS.
With special conditions I mean that
- you are on JDK 1.5 AND
- your JRE cache is completely empty AND
- the applet starts for the first time (no reload) AND
- the applet is accessed via (SUN's) web-proxy (no direct connection)

All these four conditions have to be true to run into the problem. If one
of these condition is false the applet plays fine.

Could be related to these bugs?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025019 or
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670429

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Clear cache for JRE 1.5 beta 3
2) Run this applet at: http://cjs.sfbay.sun.com/getjava/videobanner/v1.html
3) The applet doesn't run the first time it loads. But if you press reload couple of times or run it again when you restart the browser (applet already cached), the applet works.

In addition, if the proxy is turned off, the applet works the first time it loads.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The applet plays a video clip.
ACTUAL -
The applet only displays the java coffee cup logo

ERROR MESSAGES/STACK TRACES THAT OCCUR :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here's the console info:
VideoBanner by VideoBanner.com
http://www.videobanner.com
(c) 2004 by VideoBanner.com
Licensed to: SUN Microsystems, Inc.
C000-0904-04-115b-SUNe200603

Clip : V3/2180916
N3
java.security.AccessControlException: access denied (java.net.SocketPermission webcache.sfbay.sun.com:8080 connect,resolve)
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.proxiedConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source)
	at java.net.URLConnection.getHeaderFieldInt(Unknown Source)
	at java.net.URLConnection.getContentLength(Unknown Source)
	at A6.run(Unknown Source)
NIS: http://129.145.128.231/getjava/videobanner/classes-mp4/sunv2_v1.vab
java.lang.RuntimeException: java.security.AccessControlException: access denied (java.net.SocketPermission webcache.sfbay.sun.com:8080 connect,resolve)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at A6.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.net.SocketPermission webcache.sfbay.sun.com:8080 connect,resolve)
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.proxiedConnect(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.setProxiedClient(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source)
	at java.net.URLConnection.getHeaderFieldInt(Unknown Source)
	at java.net.URLConnection.getContentLength(Unknown Source)
	... 1 more
L-Time: 0
D0
D1

REPRODUCIBILITY :
This bug can be reproduced always.
(Incident Review ID: 295607) 
======================================================================
Comments
Little or not interest, or activity, on this issue recently. Closing
20-07-2017
EVALUATION I don't think this is a regression so I am removing the regression keyword. We will look at it for dolphin, or if someone can provide a working test case (the test site in the description is no longer available) we could look at it for a mustang update.
03-08-2006
EVALUATION Probably the same underlying cause as 5075841 ###@###.### 2004-08-03 I think the problem is also related to the socket permission check done in HttpURLConnection. I think there are cases where this check shouldn't be done, as when we are doing a retry. I believe what triggers this is an unusual behaviour on the part of the proxy server. It can send back a TCP Fin packet after a sucessful HTTP transaction, thus triggering a HTTP retry, which leads to the socket permission check. Once I configured the HTTP connection to bypass proxy server (note, not only do you need to specify bypassing .sfbay.sun.com, you also need to specify bypassing the actual IP address of the server, because IP address is directly quoted in the URLs used), the problem disappears. BTW, the proxy server that demonstrate this unusual behaviour is iPlanet-Web-Proxy-Server/3.6 We should fix the socket permission check in an update release for Tiger. ###@###.### 2004-08-10 As of today there three issues to be considered: 1. DNS resolution. Apparently, if the JSP page is changed to use a direct IP address instead of a hostname, everything works ok 2. The security check, which needs to be removed (from the retry path) 3. GC finalization issue, which closes the socket (apparently) while it is in the Keep alive cache. None of these issues are considered to be tiger show stoppers so I am going to lower the bugs priority. ###@###.### 2004-08-13
13-08-2004