|
Quick Lists
|
|
Bug ID:
|
4677404
|
|
Votes
|
1
|
|
Synopsis
|
REGRESSION: Webstart takes minutes to start an app
|
|
Category
|
javawebstart:other
|
|
Reported Against
|
1.0.1
|
|
Release Fixed
|
|
|
State
|
11-Closed, duplicate of 4751780,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
4751780
|
|
Submit Date
|
30-APR-2002
|
|
Description
|
FULL PRODUCT VERSION :
JDK 1.4.0, I don't have it installed anymore so can't give exact string.
FULL OPERATING SYSTEM VERSION :
customer Windows 2000 [Version 5.00.2195]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Behind a customer Proxy server
A DESCRIPTION OF THE PROBLEM :
When starting up WebStart apps startup pauses for several
minutes at "Checking for latest version". Here is some more
detailed background see this thread from the WebStart forum:
Our team ran into the same problem trying to connect to one of our test web servers, when the client ran Webstart using JRE 1.4 from behind a certain evil
Proxy Server, Webstart would get stuck in the "Checking for latest version". Note that this only happens when behind the proxy, everything runs fine with
a direct connection and users behind the proxy using JRE 1.3 also did not experience any problems. We later discovered that Webstart would complete the downloading of updates and run our app, only it would take 40 minutes to complete (left it running overnight). The strange thing was that this problem only occured when connecting to certain web servers of ours while there was absolutely no problem whatsover when connecting to other servers.
What we found was that when Webstart made a request (HEAD and later GET), the server would send the header/file back correctly. But we did notice one thing. For the servers that were "working" we noticed that it would send the response and then close the connection. But for servers that weren't working we discovered that it would send back the response but it WOULD NOT immediately close the connection. Instead the connection is kept alive until a few minutes later.
The solution was that for web servers that were working, we had the KEEP CONNECTION ALIVE option OFF. (In the case of IIS its the Keep-Alive checkbox).
On web servers that weren't working (Webstart getting stuck checking for updates) the Keep alive option was ON. That was the problem. Once we disabled
the Keep-Alive option on all our web servers everything was fine and users behind the proxy, using webstart with jre 1.4 were once again able to
Check for Updates quickly and proceed to launch the app, whereas before it would take 40 minutes to Check for Updates and load the app because for each request it had to wait for the connection to time out (900 seconds) before the next request could be made.
Well thats what we found in our research. We were pulling our hair over this for nearly a week. Hope this helps.
more information can be found at:
http://forum.java.sun.com/thread.jsp?forum=38&thread=71060
REGRESSION. Last worked with JRE version 1.3.1
This bug can be reproduced always.
(Review ID: 144897)
======================================================================
|
|
Work Around
|
N/A
|
|
Evaluation
|
no evidence that this is a regression. problem localized to MS Proxy server
(possiblely related to bad timestamps returned problem ?) Investigate for mantis
xxxxx@xxxxx 2002-05-06
Although we can't be sure that there arn't other instances of this, I am
closing this as a duplicate of 4751780. We found a repoducable case where
not closing the connections caused this long hang, and fixed it by closing
all connections.
xxxxx@xxxxx 2002-12-09
|
|
Comments
|
Submitted On 19-NOV-2003
ppimenta
The problem persists in jws 1.4.2_02(build b03), and yes the
problem is somehow related to the connection.
Here is my practical knowhow:
- In a very older version of jws, the problem doen't
exist.
- Just changing the HTTP Server the problem may
dissapear
A - 2 machines with TomCat - no problem
B - 1 machine with oracle9ias 9.0.2
(Apache HTTP Server) - problem
C - 1 machine with oracle9ias 9.0.2
(Apache HTTP Server) - no problem
In B if we went to http.conf and put KeepAlive from on to off,
then the problem would disapear.
In C the Keepalive parameter was set to on neverless it was
not afected by the problem.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |