FULL PRODUCT VERSION :
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Method HttpURLConnection.connect() takes from 3 to 10 seconds before it tries to actually connect to the server (send SYN packet) if TCP port number in URL is 8000. If port number is 80 then everything works fine.

My further investigation shows the reported problem related to a wrongful
interpretation by Java VM of an URL string used by the
HttpURLConnection.connect() method if URL contains port other then 80 or 443
(ports 80 and 443 work fine).
If, for example, URL is

	http://10.187.225.84:8000/Bitmap01.png

then Java VM first tries to use name resolution service (sends UDP datagram
packet to 10.187.225.84, port 137) which will fail if HTTP server runs on
the operating system that doesn't provide name resolution or DNS or is
behind a firewall. If server doesn't send reply on UDP port 137, VM retries
6 times about every 1 second period and only then sends TCP SYN packet
(tries to open TCP connection). 
You won't be able to see the delay if your HTTP server runs on OS that
supports DNS (like MS Windows) and UDP port 137 is open.

Hence, to fix this bug you should find code where you call name resolution
functions, if you use C sockets it will be 

    gethostbyname()
    gethostbyaddr(),

put a breakpoint there and call connect to the URL like 
    "http://10.187.225.84:8000/x.jpg".
If you are using other name resolution services then the function will be
different, but the bottom line is: VM should not try to resolve numeric IP
addresses like 10.187.225.84 as DNS name, otherwise depending on DNS server
and network configuration the connect() will take ~5-10 seconds. Now
multiply it by the number of files and you may get 5 minutes of loading time
for a simple page.

To detect the problem you may need a network protocol analyzer, like
CommView I am using. Below is a detailed network packets exchange log
demonstrating the problem. VM runs at address 10.187.226.115, HTTP server is
at 10.187.225.88 and allows access to its TCP port 8000 only.
The first two packets (#375,379) are name resolution requests sent by Java
VM and the #414 is the TCP connection request sent out only 5 seconds later.
Name resolution packets are not sent and connections established immediately
if port is either 80 or 443.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Configure your HTTP server to run on port 8000. Write client app, create HttpURLConnection and then call connect().

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Client should send TCP SYN packet immediately.
ACTUAL -
Client sends TCP SYN packet after 3-10 seconds.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
					conn = (HttpURLConnection) ResourceName.openConnection();
					conn.setUseCaches(true);
/*JHD2AI*/ System.out.println("rHD3 OpenConn");

					//
					//  The Sun bug: vm keeps connection open but doesn't re-use it.
					//	Notify the server about specifics of this client.
					//	Depending of situation (server platform, available connections)
					//	the server will take appropriate actions
					//
					conn.addRequestProperty("X-Connection","close");

					//
					//	Open TCP connection, send HTTP request message and
					//	get the reply back.
					//
/*JHD2AI*/ System.out.println("rHD3.5 conn.connect("+ResourceName+")");
					conn.connect();
/*JHD2AI*/ System.out.println("rHD4 Conn");


---------- END SOURCE ----------
###@###.### 2005-1-31 04:58:18 GMT