JDK-6660037 : Continued problems with upnext.com applet
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-02-06
  • Updated: 2010-09-08
  • Resolved: 2008-06-16
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.
JDK 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-4916766 - CORBA COMM_FAILURE when destroy() takes too long and close() happens
Relates :  
JDK-6609273 - Plugin2: Unable to load applet dynamically on IE using document.writeln utility
Relates :  
JDK-6642444 - Upnext applet resource fails to load
Description
This CR is to track the continued problems with upnext.com applet using the new plug-in in CR#6642444

** Reproducing Environment:
XP-home(sp2)/XP-pro(sp2)/ IE 6, IE7
win 2003 SE/ IE7
Tested builds: 
-Promoted jre 6u10-b11
-nightly deployment jre160.exe (01/31/2008 build)

Problem: Applet resources fail to download to the client machine at:
<System-drive>\Documents and Settings\<user>\.upnext
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6660037.2
22-02-2008
EVALUATION The root cause of this problem is something the applet is doing which is highly suspect. This particular applet, which is signed, contains some fairly sophisticated workarounds for problems in the old Java Plug-In, including inserting a worker thread in the system ThreadGroup. This worker thread attempts to make a network connection. In the new Java Plug-In, all communication between the attached JVMs and the browser is intended to be "scoped" within a particular applet, and in some places (fetching of proxy and cookie information, among others) we rely on being able to figure out which applet is making a particular request of the browser. Because this network request was being made outside the ThreadGroup and therefore AppContext of the applet, we couldn't determine the associated applet and made a request of the web browser with an invalid (-1) applet ID. The browser side code simply returned an error rather than the proxy expected by the client JVM, and the client JVM attempted to make a direct network connection, which didn't work on the test machine which required a proxy server to be specified. Logging output from the applet is attached as upnext-thread-dump.txt. Note that Thread-10 is the thread making the proxy query, and note from the dump of the ThreadGroups the follow its thread dump that it is contained in the system ThreadGroup. If this were the only reason to make a change, this bug would be closed as "will not fix". However, for robustness reasons we had intended for certain requests (in particular, for proxy and cookie information) to be able to be made from the plugin's internal AppContext. It was a bug in the new plug-in that this mechanism was not working as previously intended. The JVMInstance has therefore been fixed to more properly handle the case where an attached JVM instance makes such queries outside the applet's AppContext. Also increased a heuristic timeout in the IExplorerPlugin class which was getting triggered too often, causing this particular applet (and any applet dynamically generating the applet tag via JavaScript) to fail to load in IE. Verified manually on the machine where the applet was failing. No other test case is feasible.
22-02-2008
EVALUATION Investigated this problem thoroughly with ###@###.###. The problem is unrelated to the earlier bug 6642444 and related ones, which had their root cause in Internet Explorer's activation sequence for our ActiveX control. After much investigation, we have found that the critical difference in behavior between the old Java Plug-In and the new Java Plug-In is that when running with the new Java Plug-In, some of the applet's resources (apparently, those downloaded manually by the applet rather than via the Java Plug-In's code) are downloaded with a direct Internet connection (proxy=DIRECT) rather than going through the proxy set by the web browser. The machines on which the applet is failing are exactly those which require a proxy server to be set and can not otherwise access these resources. We don't yet know the root cause of the behavioral change between the old and the new plug-ins. However, we are in agreement that since this is not a recent regression in the new Java Plug-In, and because the failure only occurs when a proxy server must be used (less and less common on the Internet today), we are downgrading this to a P3 to prevent it from being a showstopper for beta. We will fix it after beta.
21-02-2008