It would be highly useful if the newly introduced http.defaultSocketTimeout property in HttpClient applied to connect as well as read, which is now possible using the new Socket.connect method. Many of the long "hang" cases that we see are in the connect rather in the subsequent I/O.It would be highly useful if the newly introduced http.defaultSocketTimeout property in HttpClient applied to connect as well as read, which is now possible using the new Socket.connect method. Many of the long "hang" cases that we see are in the connect rather in the subsequent I/O.

N/A

Make sense. Actually, it makes even more sense to extend the idea to other
Network clients like FTP & SMTP. That's why we decided to change the property
from http.defaultSocketTimeout to net.client.defaultSocketTimeout. It will now
cover both connects & reads.


jean- xxxxx@xxxxx  2001-03-01

Neither of the system properties seem to have any effect 
with the version of JDK I have installed.

java -version info.
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed 
mode)

What version will this show up at? It'd solve at least one 
critical networking issues for me. If it should be working 
in the version of JDK I have is there a working .java file 
out there that shows an example of this in action?

The system properties appear to have changed names 
somewhere in Sun's development cycle.  In J2SDK 1.4.1 they 
appear to be called sun.net.client.defaultConnectTimeout and 
sun.net.client.defaultReadTimeout.  See 
http://java.sun.com/j2se/1.4.1/docs/guide/net/properties.html
 for more information.

Even the sun.net.clinet.defaultSocketTimeout is working. Any bugs with java version 1.4.2_05 on Linux 2.4.21-20.EL

Please advise.