JDK-6245589 : sun.net.client.defaultReadTimeout appears to be cached
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2005-03-24
  • Updated: 2010-04-02
  • Resolved: 2005-06-13
Description
FULL PRODUCT VERSION :
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)


A DESCRIPTION OF THE PROBLEM :
When the system property sun.net.client.defaultReadTimeout is set it is supposed to cause an SocketTimeoutException to be thrown if the timeout is passed. However it appears that after a URLConnection is used once setting the property does nothing


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
First run the beanshell script provided. Notice no exception is thrown. Then uncomment the first System.setProperty().  Now an Exception is thrown on the first run.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If we wait to set the property after the first run, a timeout should occur in the second run.
ACTUAL -
If we don't set it before the first run we can't set it ever

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
#! /usr/local/jdk/bin/java  bsh.Interpreter

//import java.net.URLConnection;


     String getFromBF(Reader bf) {
        final int ca_size = 1024;
        StringBuffer answer = new StringBuffer();
        char[] ca = new char[ca_size];
        int read = 0; //declared outside loop so the while() can access it.
        int total = 0;
        do {
            read = bf.read(ca,0,ca_size);
            if (read > 0){
                answer.append(ca,0,read);//append chars we just read to answer.
                total += read;
            }
            //if we read in less chars than we asked for, or -1 for end of stream, exit loop.
        } while (read >= ca_size );
        bf.close();
        return answer.toString();
    }

url = new java.net.URL("http://login.m.xtenit.com/timeout.jsp?to=7000");

//System.setProperty("sun.net.client.defaultReadTimeout","6000");

conn = url.openConnection() ;
System.out.println("classname: "+conn.getClass().getName());

System.out.println("response code: "+conn.getResponseCode()) ;
is = conn.getInputStream() ;
s = getFromBF(new InputStreamReader(is));
System.out.println(s);

System.setProperty("sun.net.client.defaultReadTimeout","6000");

// now do it again
System.setProperty("sun.net.client.defaultReadTimeout","6000");

conn = url.openConnection() ;
System.out.println("classname: "+conn.getClass().getName());

System.out.println("response code: "+conn.getResponseCode()) ;
is = conn.getInputStream() ;
s = getFromBF(new InputStreamReader(is));
System.out.println(s);

System.setProperty("sun.net.client.defaultReadTimeout","6000");


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
In jdk 1.5 there won't be as much need to use properties, but this should still work.
###@###.### 2005-03-24 17:19:42 GMT

Comments
EVALUATION Yes, it is cached, or more precisely it is looked up only at startup time. This is by design. This was meant as a workaround for some of the limitations of the API at the time, it was never meant to be a dynamic setting. Since then we have introduced public APIs to deal with timeouts in a much more flexible way. See URLConnection.setConnectTimeout(), URLConnection.setReadTimeout() or Socket.connect() for examples. ###@###.### 2005-06-13 16:28:03 GMT
13-06-2005